HydrogenAudio

CD-R and Audio Hardware => CUETools => Topic started by: Gregory S. Chudov on 2008-10-02 12:26:13

Title: CUETools versions 1.9.5 through 2.1.6
Post by: Gregory S. Chudov on 2008-10-02 12:26:13
Please welcome, CUETools v2.1.6. (CUETools download page (http://cue.tools/wiki/CUETools_Download)) or direct link: http://www.cuetools.net/install/CUETools_2.1.6.zip (http://www.cuetools.net/install/CUETools_2.1.6.zip)

Dec 09 2014: CUETools 2.1.6:
* CUETools: Fixed issue with setting profiles
* CUETools: FLAC encoder optimized using new window functions by ktf
* CUETools: libFLAC updated to 1.3.1
* CUETools: fixed a bug where external decoders would not start


Please welcome, CUETools v2.1.5. (CUETools download page (http://cue.tools/wiki/CUETools_Download)) or direct link: http://www.cuetools.net/install/CUETools_2.1.5.zip (http://www.cuetools.net/install/CUETools_2.1.5.zip)

04.07.2013: CUETools 2.1.5:
* CUETools: added support for CDTOC tag to help determine pre-gap and data track info
* CUETools: added button for easier access to encoder settings
* CUETools: support for non-subset FLAC modes disabled by default
* CUETools: built-in managed encoders (libFlake, libALAC, etc) renamed to 'cuetools' for simplicity
* CUETools: CUETools FLAC decoder optimized; verification now works around 50% faster when not limited by I/O
* CUETools: to simplify the interface, removed lossyWAV support; encoder was outdated anyway
* CUETools: added support for WMA lossless as input and both WMA lossless and lossy as output
* CUETools: cleaned up encoder/decoder pages in advanced settings
* CUETools: treat batch jobs with only 1 album as non-batch, i.e. allow interactive UI, such as repair dialog
* CUETools: use TRACKTOTAL, DISCTOTAL, ALBUMARTIST tags instead of old style fb2k TOTALTRACKS, TOTALDISCS, ALBUM ARTIST
* CUETools: CTDB verification can be enabled during encoding
* CUETools: CTDB verification results can be saved as tags
* CUETools: libFLAC updated to 1.3.0
* CUETools: removed reference to the CSScriptLibrary
* CUERipper: right-click on the album art shows an enlarged fragment of it
* CUERipper: clicking through all available cover art selects 'no cover art'
* CUERipper: hovering over album art shows album art URL
* CUERipper: track quality is correctly reported in EAC-style log
* CUERipper: Test & Copy now works for drives that fail gap-detection
* CUERipper: remember chosen format & offset between restarts
* CUERipper: track comments saved as tags
* CUERipper: disc load/eject button
* CUETools.Converter: added support for encoding to lossy formats
* CUETools.Converter: added support multi-channel audio
* CUETools.Converter: added support for stdin/stdout
* CUETools.Converter: added support for different compression levels
* ArCueDotNet.exe: added CTDB support
* FLACCL: hi-res audio support
* FLACCL: Intel HD Graphics support
* Various bug fixes



IMPORTANT: .NET Framework 2.0 (SP2) (http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f&displaylang=en) 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, (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf)x64 (http://www.microsoft.com/downloads/details.aspx?familyid=BD2A6171-E2D6-4230-B809-9A8D7548C1B6&displaylang=en)) is installed.

The source code can be downloaded from the project's Mercurial repository (http://sourceforge.net/p/cuetoolsnet/code/) at SourceForge.
Note: The repository has moved. The latest source code can be downloaded from the project's repository (https://github.com/gchudov/cuetools.net) at GitHub.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2008-10-03 17:11:20
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>
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: foorious on 2008-10-03 18:17:56
Hi, Gregory sent me to this thread from this one : http://www.hydrogenaudio.org/forums/index....showtopic=56531 (http://www.hydrogenaudio.org/forums/index.php?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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-04 02:48:48
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 (http://www.hydrogenaudio.org/forums/index.php?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: [Select]
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2008-10-04 14:53:52
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-04 22:53:10
I encountered some very strange logs:
Code: [Select]
[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: [Select]
[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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2008-10-04 23:49:01
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?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Raiden on 2008-10-05 00:34:16
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: [Select]
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 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-05 14:57:38
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?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Raiden on 2008-10-05 20:39:05
It now says (excerpt):
Code: [Select]
  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!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: foorious on 2008-10-05 21:58:38
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...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2008-10-06 00:53:11
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?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-06 15:40:02
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?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2008-10-07 00:15:04
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: [Select]
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: [Select]
[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:
[a href="http://img161.imageshack.us/my.php?image=tripleflacreportyn7.png" target="_blank"]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2008-10-07 04:12:31
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Moitah on 2008-10-07 05:48:28
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2008-10-07 07:07:07
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".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-07 18:25:02
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-07 19:51:46
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-07 23:10:59
So why CUE Tools didn't find that -1501 offset? 


Thanks a lot, looks like i fixed it!

Code: [Select]
[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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2008-10-08 00:32:06
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: [Select]
[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!:
(http://img146.imageshack.us/img146/1756/tripleflacreport3ss9.th.png) (http://img146.imageshack.us/my.php?image=tripleflacreport3ss9.png)(http://img146.imageshack.us/images/thpix.gif) (http://g.imageshack.us/thpix.php)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-08 01:47:15
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
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2008-10-08 08:58:20
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
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-08 13:56:04
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: foorious on 2008-10-08 14:49:31
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)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2008-10-08 16:04:02
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.


How are you calculating offsets, exactly?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2008-10-08 16:31:36
Correct AR has 2 CRCs one for the track, the other for 1 sector in the track for offset detection.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-08 17:00:18
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.


How are you calculating offsets, exactly?


Simple math.
Basicly, ArCRC = sum ( N * Sample[N] );
If there is an offset by S samples, original ArCRC = sum ( (N-S) * Sample[N] ).
So when i process a track, i calculate two sums:
ArCRC and offset correction CRC: OcCRC = sum ( Sample[N]);
We can calculate offsetted CRC very fast and simple:
sum ( (N-S) * Sample[N] ) = sum ( N * Sample[N] ) - S * sum ( Sample[N] ) = ArCRC - S * OcCRC.
We do it for every S in range of +- 5 frames, and search for the match.
So we don't really need that second CRC from the database to find an offset for a correctly ripped track.
Of course, in practice it's all a bit more complicated around the track boundaries.

Correct AR has 2 CRCs one for the track, the other for 1 sector in the track for offset detection.


Thanks a lot, that's very useful information. And thanks again for the database and permission to use it
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Moitah on 2008-10-08 17:34:04
@spoon: Is there a way to query the AccurateRip database via the web to get a list of AccurateRip Disc IDs that correspond to/contain a certain FreeDB Disc ID?  This would allow us to determine the AccurateRip Disc ID for a CD with a data track if the cuesheet contained a "REM DISCID" line.  In fact, it's even possible to do this now since the length of the data track can be determined to within a 1 second range based on the FreeDB Disc ID, but I'm sure you don't want us querying 75 times (max) to figure out which one is correct.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-09 20:35:30
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.


Try it with new version. You can turn off offset correction in Advanced settings, and it will do almost what you asked - autoverification after conversion. Autoverification before conversion, in fact

But here's another strange one. 


And try this jazz trio again

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.

I hope the new version does what you need.
You can turn on "Encode only if" option in Avanced settings, set up the confidence levels, turn off offset correction if you like, and run it in "Fix offset" mode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: foorious on 2008-10-10 01:24:26
I think I have the same problem as "No Fun", or at least a similar problem.

I've tried CUETools (latest version available in this topic - "Update 4") on one album I'm totally certain of : Alanis Morissette - Jagged Little Pill. This album was my absolute personal AccurateRip record a year and a half ago, with a confidence score of 181. So I'm quite certain it's a perfect rip, and a well-known one from AccurateRip's point of view.

So we start from 14 separate FLAC files, with no cuesheet at all. With CUETools "CUE Sheet Creator" button, I create a dummy cuesheet. Here it is :

Code: [Select]
REM COMMENT "CUETools generated dummy CUE sheet"
FILE "01 - All I Really Want.flac" WAVE
  TRACK 01 AUDIO
INDEX 01 00:00:00
FILE "02 - You Oughta Know.flac" WAVE
  TRACK 02 AUDIO
INDEX 01 00:00:00
FILE "03 - Perfect.flac" WAVE
  TRACK 03 AUDIO
INDEX 01 00:00:00
FILE "04 - Hand In My Pocket.flac" WAVE
  TRACK 04 AUDIO
INDEX 01 00:00:00
FILE "05 - Right Through You.flac" WAVE
  TRACK 05 AUDIO
INDEX 01 00:00:00
FILE "06 - Forgiven.flac" WAVE
  TRACK 06 AUDIO
INDEX 01 00:00:00
FILE "07 - You Learn.flac" WAVE
  TRACK 07 AUDIO
INDEX 01 00:00:00
FILE "08 - Head Over Feet.flac" WAVE
  TRACK 08 AUDIO
INDEX 01 00:00:00
FILE "09 - Mary Jane.flac" WAVE
  TRACK 09 AUDIO
INDEX 01 00:00:00
FILE "10 - Ironic.flac" WAVE
  TRACK 10 AUDIO
INDEX 01 00:00:00
FILE "11 - Not The Doctor.flac" WAVE
  TRACK 11 AUDIO
INDEX 01 00:00:00
FILE "12 - Wake Up.flac" WAVE
  TRACK 12 AUDIO
INDEX 01 00:00:00
FILE "13 - You Oughta Know (Alternate Take).flac" WAVE
  TRACK 13 AUDIO
INDEX 01 00:00:00
FILE "14 - Hidden Track.flac" WAVE
  TRACK 14 AUDIO
INDEX 01 00:00:00
Then I set the Audio Output to "none", AccurateRip to "Verify", and I click on "Convert" (maybe "Analyze" would be better in this case IMHO). Here are the results in the dialog box :

Code: [Select]
[Disc ID: 001d2cdc-0137a6e5-bc0d410e]
Track [ CRC ] Status
 01 [00000000] Disk not present in database.
 02 [00000000] Disk not present in database.
 03 [00000000] Disk not present in database.
 04 [00000000] Disk not present in database.
 05 [00000000] Disk not present in database.
 06 [00000000] Disk not present in database.
 07 [00000000] Disk not present in database.
 08 [00000000] Disk not present in database.
 09 [00000000] Disk not present in database.
 10 [00000000] Disk not present in database.
 11 [00000000] Disk not present in database.
 12 [00000000] Disk not present in database.
 13 [00000000] Disk not present in database.
 14 [00000000] Disk not present in database.
Same thing if I set AccurateRip to "Fix Offset" (although I'm certain my offset is good here)

Obviously there's something wrong here...


EDIT - Gregory, regarding the "Fix Offset" mode, personally I am interested in CUETools mainly for verification purposes. I'd like a tool that will help me batch-analyze all my CDs and write relevant AccurateRip info : AR info(accurate rip, different pressing, not present, not accurate), AR confidence score, etc... directly to the file tags, all in a single operation.
E.g. : AR info tag = "Accurate Rip" and AR confidence tag = "181".
Then with foobar I will easily locate all suspicious CDs and decide myself what to do with them (or not). What I want to say is that I too don't want CUETools to automatically perform conversions. I'd like it to only test the files, and then I'll decide what I want to do or not.
An idea could be to include the "Verify Offset" feature into the "Verify" option. So with "Verify" we could (1) verify against the AR database with no offset correction, and (2) try other offsets if necessary then verify again. All this without conversion.

Thank you again for all your work. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Moitah on 2008-10-10 04:01:01
@foorious:  I checked freedb/Amazon and it looks like that hidden track was part of track 13, so I think you or whoever ripped it split it into a separate file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: foorious on 2008-10-10 10:32:52
Oh, that's too bad : I have manually splitted hidden tracks in maybe 10 albums over more than 1000, and this seems to be one of them. Apologies ! I have tried rejoining tracks 13 and 14 using foobar, tested again, and the problem remains the same. Maybe I've manually removed the silence between both tracks, so I'd better pick another album.

However, what would be great would be if CUETools could still be able to give an AccurateRip confidence score for tracks 01-12 that have been perfectly ripped...  Ideally it should skip track 14, say that tracks 01-12 are accurate, track 13 isn't (since it has been splitted), and track 14 is unknown for this album.

Let's give it another try with "The Eminem Show", with an AR score of 131 a year ago. The good news is that CUETools works.  Now here are the results :
Code: [Select]
[Disc ID: 0037a240-033958f4-f2122a14]
Track [ CRC ] Status
 01 [4e72a4c7] (200/229) Accurately ripped as in pressing(s) #1
 02 [5067c665] (200/231) Accurately ripped as in pressing(s) #2
 03 [743e0797] (200/230) Accurately ripped as in pressing(s) #2
 04 [6458502e] (200/230) Accurately ripped as in pressing(s) #2
 05 [a64967d7] (200/234) Accurately ripped as in pressing(s) #2
 06 [51eb46fb] (200/231) Accurately ripped as in pressing(s) #2
 07 [8d2df3dc] (200/230) Accurately ripped as in pressing(s) #2
 08 [c352fc4e] (200/230) Accurately ripped as in pressing(s) #2
 09 [85d7fd90] (200/230) Accurately ripped as in pressing(s) #2
 10 [4ad9cfcf] (200/230) Accurately ripped as in pressing(s) #2
 11 [deaa2b28] (200/229) Accurately ripped as in pressing(s) #2
 12 [c33c9809] (200/228) Accurately ripped as in pressing(s) #2
 13 [dc2adb6d] (200/231) Accurately ripped as in pressing(s) #2
 14 [a08ecb26] (200/227) Accurately ripped as in pressing(s) #2
 15 [6058d3ad] (200/227) Accurately ripped as in pressing(s) #2
 16 [3679cc8b] (200/230) Accurately ripped as in pressing(s) #2
 17 [de921b13] (200/233) Accurately ripped as in pressing(s) #2
 18 [cdf03864] (200/229) Accurately ripped as in pressing(s) #2
 19 [182e9e00] (200/227) Accurately ripped as in pressing(s) #2
 20 [1472b5f2] (200/228) Accurately ripped as in pressing(s) #1
Offsetted by -1292:
 01 [2283a122] (02/229) Accurately ripped as in pressing(s) #7
 02 [748b9a16] (03/231) Accurately ripped as in pressing(s) #4
 03 [3a302f22] (03/230) Accurately ripped as in pressing(s) #4
 04 [fbb556ee] (03/230) Accurately ripped as in pressing(s) #4
 05 [4ab21fa9] (03/234) Accurately ripped as in pressing(s) #4
 06 [6eaee4a0] (02/231) Accurately ripped as in pressing(s) #7
 07 [c499eb91] (03/230) Accurately ripped as in pressing(s) #4
 08 [bc923bf3] (03/230) Accurately ripped as in pressing(s) #4
 09 [84092bf7] (03/230) Accurately ripped as in pressing(s) #4
 10 [69ffc4dc] (03/230) Accurately ripped as in pressing(s) #4
 11 [82c7ac88] (03/229) Accurately ripped as in pressing(s) #4
 12 [842870f4] (03/228) Accurately ripped as in pressing(s) #4
 13 [c35d77a7] (03/231) Accurately ripped as in pressing(s) #4
 14 [34039f7d] (03/227) Accurately ripped as in pressing(s) #4
 15 [e9637259] (03/227) Accurately ripped as in pressing(s) #4
 16 [ceb12b4c] (03/230) Accurately ripped as in pressing(s) #4
 17 [60502ae4] (03/233) Accurately ripped as in pressing(s) #4
 18 [16d8d257] (03/229) Accurately ripped as in pressing(s) #4
 19 [b934d324] (02/227) Accurately ripped as in pressing(s) #4
 20 [66cdcc1c] (02/228) Accurately ripped as in pressing(s) #8
Offsetted by -667:
 01 [f519d188] (05/229) Accurately ripped as in pressing(s) #3
 02 [41146252] (05/231) Accurately ripped as in pressing(s) #5
 03 [c9fc9127] (04/230) Accurately ripped as in pressing(s) #6
 04 [cb5d04e0] (04/230) Accurately ripped as in pressing(s) #6
 05 [9a4f6e7c] (05/234) Accurately ripped as in pressing(s) #5
 06 [35a24389] (05/231) Accurately ripped as in pressing(s) #4
 07 [02b217ec] (04/230) Accurately ripped as in pressing(s) #6
 08 [94f81271] (04/230) Accurately ripped as in pressing(s) #6
 09 [958cdce8] (04/230) Accurately ripped as in pressing(s) #6
 10 [47cb5cbf] (05/230) Accurately ripped as in pressing(s) #5
 11 [2dc2b084] (04/229) Accurately ripped as in pressing(s) #6
 12 [8410aceb] (03/228) Accurately ripped as in pressing(s) #6
 13 [fb401505] (04/231) Accurately ripped as in pressing(s) #6
 14 [e38bf06e] (04/227) Accurately ripped as in pressing(s) #5
 15 [366e1bb3] (04/227) Accurately ripped as in pressing(s) #5
 16 [44c2823a] (03/230) Accurately ripped as in pressing(s) #6
 17 [2e26ab5f] (04/233) Accurately ripped as in pressing(s) #6
 18 [a290ace0] (04/229) Accurately ripped as in pressing(s) #6
 19 [eff146b7] (04/227) Accurately ripped as in pressing(s) #7
 20 [0083aa32] (04/228) Accurately ripped as in pressing(s) #6
Offsetted by -649:
 01 [4f5f41ac] (02/229) Accurately ripped as in pressing(s) #8
 02 [197ea526] (02/231) Accurately ripped as in pressing(s) #8
 03 [bea615d7] (02/230) Accurately ripped as in pressing(s) #8
 04 [a846eab4] (02/230) Accurately ripped as in pressing(s) #8
 05 [83d32d84] (02/234) Accurately ripped as in pressing(s) #8
 06 [c8c2430d] (02/231) Accurately ripped as in pressing(s) #8
 07 [b3a571ba] (02/230) Accurately ripped as in pressing(s) #8
 08 [57352b0d] (02/230) Accurately ripped as in pressing(s) #8
 09 [62e23292] (02/230) Accurately ripped as in pressing(s) #8
 10 [495fbab0] (02/230) Accurately ripped as in pressing(s) #8
 11 [5243aba8] (02/229) Accurately ripped as in pressing(s) #8
 12 [f36e39d1] (02/228) Accurately ripped as in pressing(s) #8
 13 [20f36626] (02/231) Accurately ripped as in pressing(s) #8
 14 [da74e8d9] (02/227) Accurately ripped as in pressing(s) #7
 15 [c4da15bb] (02/227) Accurately ripped as in pressing(s) #7
 16 [1e00f9c6] (02/230) Accurately ripped as in pressing(s) #8
 17 [f496b548] (02/233) Accurately ripped as in pressing(s) #8
 18 [3b62ba40] (02/229) Accurately ripped as in pressing(s) #8
 19 [7bd1fc66] (02/227) Accurately ripped as in pressing(s) #9
 20 [6e60667f] (02/228) Accurately ripped as in pressing(s) #9
Offsetted by -646:
 01 [0e792b20] (08/229) Accurately ripped as in pressing(s) #2
 02 [6fa42e5d] (08/231) Accurately ripped as in pressing(s) #3
 03 [1ccb28d1] (08/230) Accurately ripped as in pressing(s) #3
 04 [c919bdc0] (08/230) Accurately ripped as in pressing(s) #3
 05 [80567094] (08/234) Accurately ripped as in pressing(s) #3
 06 [38cda00b] (08/231) Accurately ripped as in pressing(s) #3
 07 [4fd11505] (08/230) Accurately ripped as in pressing(s) #3
 08 [f794af27] (08/230) Accurately ripped as in pressing(s) #3
 09 [dea7732b] (08/230) Accurately ripped as in pressing(s) #3
 10 [82266a65] (07/230) Accurately ripped as in pressing(s) #3
 11 [30436600] (07/229) Accurately ripped as in pressing(s) #3
 12 [eccef0d0] (07/228) Accurately ripped as in pressing(s) #3
 13 [20934d20] (08/231) Accurately ripped as in pressing(s) #3
 14 [e531d34e] (08/227) Accurately ripped as in pressing(s) #3
 15 [d93100dd] (08/227) Accurately ripped as in pressing(s) #3
 16 [e7fc0e4f] (08/230) Accurately ripped as in pressing(s) #3
 17 [9ffe1eec] (08/233) Accurately ripped as in pressing(s) #3
 18 [06cf2f55] (07/229) Accurately ripped as in pressing(s) #3
 19 [fc46b55b] (07/227) Accurately ripped as in pressing(s) #3
 20 [d54c073b] (08/228) Accurately ripped as in pressing(s) #2
Offsetted by -6:
 01 [3edb878e] (04/229) Accurately ripped as in pressing(s) #5
 02 [75f100e6] (03/231) Accurately ripped as in pressing(s) #7
 03 [8ab2054e] (03/230) Accurately ripped as in pressing(s) #7
 04 [14e58fcc] (03/230) Accurately ripped as in pressing(s) #7
 05 [7f7fdf2b] (03/234) Accurately ripped as in pressing(s) #7
 06 [3007a36e] (03/231) Accurately ripped as in pressing(s) #6
 07 [6422e15b] (03/230) Accurately ripped as in pressing(s) #7
 08 [eee6b1e6] (03/230) Accurately ripped as in pressing(s) #7
 09 [67264ec9] (03/230) Accurately ripped as in pressing(s) #7
 10 [615600f2] (03/230) Accurately ripped as in pressing(s) #7
 11 [5489d199] (03/229) Accurately ripped as in pressing(s) #7
 12 [54b78349] (03/228) Accurately ripped as in pressing(s) #7
 13 [0e07c10c] (03/231) Accurately ripped as in pressing(s) #7
 14 [67225b15] (03/227) Accurately ripped as in pressing(s) #6
 15 [573e8824] (03/227) Accurately ripped as in pressing(s) #6
 16 [5d764362] (03/230) Accurately ripped as in pressing(s) #7
 17 [91274e2d] (03/233) Accurately ripped as in pressing(s) #7
 18 [210ea414] (03/229) Accurately ripped as in pressing(s) #7
 19 [de49a93c] (03/227) Accurately ripped as in pressing(s) #8
 20 [ddd6f7a9] (03/228) Accurately ripped as in pressing(s) #7
Offsetted by 6:
 01 [287a0269] (04/229) Accurately ripped as in pressing(s) #6
 02 [bf762232] (06/231) Accurately ripped as in pressing(s) #1
 03 [b5e2f1e2] (06/230) Accurately ripped as in pressing(s) #1
 04 [b11510f1] (06/230) Accurately ripped as in pressing(s) #1
 05 [ceb49c26] (07/234) Accurately ripped as in pressing(s) #1
 06 [57c9ad9d] (07/231) Accurately ripped as in pressing(s) #1
 07 [dc195675] (06/230) Accurately ripped as in pressing(s) #1
 08 [6bb00e8c] (06/230) Accurately ripped as in pressing(s) #1
 09 [d712cbd5] (06/230) Accurately ripped as in pressing(s) #1
 10 [57b131bc] (06/230) Accurately ripped as in pressing(s) #1
 11 [ab12c627] (06/229) Accurately ripped as in pressing(s) #1
 12 [7ab1d63f] (06/228) Accurately ripped as in pressing(s) #1
 13 [43e9ba7a] (07/231) Accurately ripped as in pressing(s) #1
 14 [41eca653] (07/227) Accurately ripped as in pressing(s) #1
 15 [946d2300] (07/227) Accurately ripped as in pressing(s) #1
 16 [6043b398] (07/230) Accurately ripped as in pressing(s) #1
 17 [1cdab6df] (07/233) Accurately ripped as in pressing(s) #1
 18 [cafa20fd] (06/229) Accurately ripped as in pressing(s) #1
 19 [34923213] (03/227) Accurately ripped as in pressing(s) #5
 20 [9985a391] (00/228) No matches
However, forgive me but I'm not sure to understand the results.
E.g. : "01   [4e72a4c7] (200/229) Accurately ripped as in pressing(s) #1"
- What does the "200/229" mean ?
- What does the "#1" mean ?

And one last thing : how can we make the results to be written directly into the file tags ?
(e.g. one tag for the CRC, one tag for the "200/229", one tag for the "Accurately ripped as in pressing(s) #1", and so on...

Thank you again Gregory for this promising software. 

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Code changed to codebox (again).[/size]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-10 11:00:41
Gregory, regarding the "Fix Offset" mode, personally I am interested in CUETools mainly for verification purposes. I'd like a tool that will help me batch-analyze all my CDs and write relevant AccurateRip info : AR info(accurate rip, different pressing, not present, not accurate), AR confidence score, etc... directly to the file tags, all in a single operation.
E.g. : AR info tag = "Accurate Rip" and AR confidence tag = "181".
Then with foobar I will easily locate all suspicious CDs and decide myself what to do with them (or not). What I want to say is that I too don't want CUETools to automatically perform conversions. I'd like it to only test the files, and then I'll decide what I want to do or not.
An idea could be to include the "Verify Offset" feature into the "Verify" option. So with "Verify" we could (1) verify against the AR database with no offset correction, and (2) try other offsets if necessary then verify again. All this without conversion.


First of all, "Verify" option does verify offsets also. "Fix" option on the first pass does exactly the same as Verify, only it then procedes with conversion (possibly using the offset found in first pass).

"Verify" also writes AR tags in source file on success, but currently only flac album image (with embedded cue) is supported for this.

So as i see it, two features are missing: writing AccurateRip tags in image that is split into tracks, and special tags for non-offset corrected rips - because right now they are tagged as inaccurate.

However, forgive me but I'm not sure to understand the results.
E.g. : "01   [4e72a4c7] (200/229) Accurately ripped as in pressing(s) #1"
- What does the "200/229" mean ?
- What does the "#1" mean ?


200/229 is the confidence level, i.e. 200 of 229 people who ripped this disc got the same results as you.

#1 means the first database entry. There are several entries for each disc in database. Is it #1 or #10, doesn't really matter.

Anyway, only confidence level is important.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-10 11:14:28
However, what would be great would be if CUETools could still be able to give an AccurateRip confidence score for tracks 01-12 that have been perfectly ripped...  Ideally it should skip track 14, say that tracks 01-12 are accurate, track 13 isn't (since it has been splitted), and track 14 is unknown for this album.


Unfortunately, this is impossible. You have to know the id of the disk to be able to compare it to the database, and diskId depends on the number and length of the tracks. So if you split a track, cut out silence - there's no way to tell which disk it is that you have.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: foorious on 2008-10-10 12:57:25
So as i see it, two features are missing: writing AccurateRip tags in image that is split into tracks, and special tags for non-offset corrected rips - because right now they are tagged as inaccurate.

Yes, definitely. These two features would be a great add-on ! 
Optionally, I see two more small features :
- Be able to choose which info is to be tagged or not (maybe with some checkboxes),
- Be able to edit the name of each tag.

200/229 is the confidence level, i.e. 200 of 229 people who ripped this disc got the same results as you.

Thanks. That's what I thought, but I prefer to be sure. Oh, just one question : if I add the confidence results for all different versions, I do not find 229. E.g. for track 1 : 200 + 2 + 5 + 2 + 8 + 4 + 4 = 225. Where are the 4 missing people ?

Unfortunately, this is impossible. You have to know the id of the disk to be able to compare it to the database, and diskId depends on the number and length of the tracks. So if you split a track, cut out silence - there's no way to tell which disk it is that you have.

Just a silly question then : when the Disk ID is impossible to figure, couldn't we at least use the %artist% and %album% tags to (1) find all versions of these albums on AR database, and (2) try some matching on a per-track basis ? Just wondering if Disk ID is the one and only way for AR...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-10 13:31:11
I do not find 229. E.g. for track 1 : 200 + 2 + 5 + 2 + 8 + 4 + 4 = 225. Where are the 4 missing people ?

The missing 4 people most probably had a scratched CD or bad drive, and ripped this disc with errors, so their CRC doesn't match even taking possible offsets into account.

Just a silly question then : when the Disk ID is impossible to figure, couldn't we at least use the %artist% and %album% tags to (1) find all versions of these albums on AR database, and (2) try some matching on a per-track basis ? Just wondering if Disk ID is the one and only way for AR...

Right now Disk ID is the one and only way for AR. There's no text search in it. There's even no search by cddb id. And even if there was, for your Alanis Morissette disk, there are 70 entries in cddb database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-11 00:29:13
Gregory,

I can't make the "encode if % of verified tracks with x confidence" mode work.

FYI, I set AccurateRip mode to "Verify". I only enable the Encode check at Advanced options, with 100% and confidence=1. It verifies but it never encodes after that.

While I'm at it, could you please add support to transfer tags while encoding ? I need to transfer APE tags to FLACs.

Thanks in advance.

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-11 12:39:37
Gregory,

I can't make the "encode if % of verified tracks with x confidence" mode work.

FYI, I set AccurateRip mode to "Verify". I only enable the Encode check at Advanced options, with 100% and confidence=1. It verifies but it never encodes after that.

While I'm at it, could you please add support to transfer tags while encoding ? I need to transfer APE tags to FLACs.

Thanks in advance.

N.


Verify option still never outputs anything.
"encode if" mode relates to "fix offset" option, which should probably be renamed now.
You can uncheck the "fix offset if" option, turn on "encode if" option and use "fix offset mode".

Support for APE tags is on my todo list.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2008-10-11 13:06:49
Thank you for the excellent new CUEtools features.

I wonder if it would be possible to add a new simple filename extension corrector that would not need to check the audio files on the disk at all.

Then you could just select the desired target extension (wav, flac, ape or wv) and mass process a bunch of cue sheets even if the audio files are not organized in separate folders.

Personally, I have stored my "single file + cue" multi-disc albums in single album folders so I would need to reorganize them before I could use the filename corrector tool for fixing the cue sheets after a file format change.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: yury_usa on 2008-10-11 22:59:22
Question:

Original Log
Code: [Select]
Exact Audio Copy V0.99 prebeta 3 from 28. July 2007

EAC extraction logfile from 15. September 2008, 16:35

California Guitar Trio / Yamanashi Blues

Used drive  : YAMAHA  CRW2100E  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 733
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Installed external ASPI interface
Gap handling                                : Appended to previous track

Used output format              : User Defined Encoder
Selected bitrate                : 768 kBit/s
Quality                        : High
Add ID3 tag                    : No
Command line compressor        : C:\Archivos de programa\Exact Audio Copy\FLAC\FLAC.EXE
Additional command line options : -6 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=%e" %s -o %d


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  2:21.52 |        0    |    10626 
        2  |  2:21.52 |  2:10.05 |    10627    |    20381 
        3  |  4:31.57 |  1:29.70 |    20382    |    27126 
        4  |  6:01.52 |  2:01.13 |    27127    |    36214 
        5  |  8:02.65 |  5:04.62 |    36215    |    59076 
        6  | 13:07.52 |  1:54.48 |    59077    |    67674 
        7  | 15:02.25 |  1:19.70 |    67675    |    73669 
        8  | 16:22.20 |  4:37.32 |    73670    |    94476 
        9  | 20:59.52 |  1:28.23 |    94477    |  101099 
      10  | 22:28.00 |  2:17.02 |    101100    |  111376 
      11  | 24:45.02 |  1:45.43 |    111377    |  119294 
      12  | 26:30.45 |  1:46.07 |    119295    |  127251 
      13  | 28:16.52 | 11:44.35 |    127252    |  180086 
      14  | 40:01.12 |  2:14.70 |    180087    |  190206 
      15  | 42:16.07 |  3:12.58 |    190207    |  204664 


Track  1

    Filename D:\Datos\audio rips\01 - Yamanashi Blues.wav

    Pre-gap length  0:00:02.00

    Peak level 87.1 %
    Track quality 100.0 %
    Test CRC CB0C5459
    Copy CRC CB0C5459
    Cannot be verified as accurate (confidence 2)  [0C56D51D], AccurateRip returned [6ACB9DE4]
    Copy OK

Track  2

    Filename D:\Datos\audio rips\02 - Melrose Avenue.wav

    Peak level 100.0 %
    Track quality 100.0 %
    Test CRC E61F48D9
    Copy CRC E61F48D9
    Cannot be verified as accurate (confidence 2)  [A4E7F44C], AccurateRip returned [8626201C]
    Copy OK

Track  3

    Filename D:\Datos\audio rips\03 - Corrente.wav

    Peak level 45.6 %
    Track quality 100.0 %
    Test CRC 0DCED459
    Copy CRC 0DCED459
    Cannot be verified as accurate (confidence 2)  [818FD48C], AccurateRip returned [B1A8D24C]
    Copy OK

Track  4

    Filename D:\Datos\audio rips\04 - Walk Don't Run.wav

    Peak level 92.8 %
    Track quality 99.9 %
    Test CRC 2740BABB
    Copy CRC 2740BABB
    Cannot be verified as accurate (confidence 2)  [7E0BF22D], AccurateRip returned [288D709D]
    Copy OK

Track  5

    Filename D:\Datos\audio rips\05 - Ricercar.wav

    Peak level 55.9 %
    Track quality 99.9 %
    Test CRC 0971BFCF
    Copy CRC 0971BFCF
    Cannot be verified as accurate (confidence 2)  [FE96930D], AccurateRip returned [A7E04B1D]
    Copy OK

Track  6

    Filename D:\Datos\audio rips\06 - Pipeline.wav

    Peak level 97.7 %
    Track quality 100.0 %
    Test CRC 6B69F644
    Copy CRC 6B69F644
    Cannot be verified as accurate (confidence 2)  [66C9EB2F], AccurateRip returned [68298E0F]
    Copy OK

Track  7

    Filename D:\Datos\audio rips\07 - Beeline.wav

    Peak level 100.0 %
    Track quality 100.0 %
    Test CRC 98FD9219
    Copy CRC 98FD9219
    Cannot be verified as accurate (confidence 2)  [47D2D9C9], AccurateRip returned [EBF33DEF]
    Copy OK

Track  8

    Filename D:\Datos\audio rips\08 - Chromatic Fugue In D Minor.wav

    Peak level 100.0 %
    Track quality 100.0 %
    Test CRC 43027130
    Copy CRC 43027130
    Cannot be verified as accurate (confidence 2)  [D14A54B1], AccurateRip returned [9BF87C1B]
    Copy OK

Track  9

    Filename D:\Datos\audio rips\09 - Tenor Madness.wav

    Peak level 97.4 %
    Track quality 99.8 %
    Test CRC 55607C9F
    Copy CRC 55607C9F
    Cannot be verified as accurate (confidence 2)  [9DE020F5], AccurateRip returned [FCA36A15]
    Copy OK

Track 10

    Filename D:\Datos\audio rips\10 - Sleewalk.wav

    Peak level 69.1 %
    Track quality 100.0 %
    Test CRC 934EA7BC
    Copy CRC 934EA7BC
    Cannot be verified as accurate (confidence 2)  [7E619E3B], AccurateRip returned [0BC6DFFB]
    Copy OK

Track 11

    Filename D:\Datos\audio rips\11 - Carnival.wav

    Peak level 66.6 %
    Track quality 99.8 %
    Test CRC D54C937A
    Copy CRC D54C937A
    Cannot be verified as accurate (confidence 2)  [200C7AF2], AccurateRip returned [4DB39EE9]
    Copy OK

Track 12

    Filename D:\Datos\audio rips\12 - Prelude In C Minor.wav

    Peak level 54.0 %
    Track quality 100.0 %
    Test CRC 22685572
    Copy CRC 22685572
    Cannot be verified as accurate (confidence 2)  [D9E0F7AE], AccurateRip returned [6B5F77AF]
    Copy OK

Track 13

    Filename D:\Datos\audio rips\13 - Ciaccona.wav

    Peak level 61.0 %
    Track quality 100.0 %
    Test CRC 38F5A639
    Copy CRC 38F5A639
    Cannot be verified as accurate (confidence 2)  [A29460B6], AccurateRip returned [0F0A5387]
    Copy OK

Track 14

    Filename D:\Datos\audio rips\14 - Blockhead.wav

    Peak level 100.0 %
    Track quality 100.0 %
    Test CRC 42266934
    Copy CRC 42266934
    Cannot be verified as accurate (confidence 2)  [C0007BA4], AccurateRip returned [45D75600]
    Copy OK

Track 15

    Filename D:\Datos\audio rips\15 - Kan-Non Power.wav

    Peak level 84.9 %
    Track quality 100.0 %
    Test CRC 0A69F0AD
    Copy CRC 0A69F0AD
    Cannot be verified as accurate (confidence 2)  [1AFEE1A0], AccurateRip returned [2F2FAE7B]
    Copy OK


No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

No errors occurred

End of status report

accuraterip result:
Code: [Select]
[Disc ID: 0015b781-00fd75be-d70aa80f]
Track [ CRC    ] Status
 01 [0c56d51d] (00/02) No matches
 02 [a4e7f44c] (00/02) No matches
 03 [818fd48c] (00/02) No matches
 04 [7e0bf22d] (00/02) No matches
 05 [fe96930d] (00/02) No matches
 06 [66c9eb2f] (00/02) No matches
 07 [47d2d9c9] (00/02) No matches
 08 [d14a54b1] (00/02) No matches
 09 [9de020f5] (00/02) No matches
 10 [7e619e3b] (00/02) No matches
 11 [200c7af2] (00/02) No matches
 12 [d9e0f7ae] (00/02) No matches
 13 [a29460b6] (00/02) No matches
 14 [c0007ba4] (00/02) No matches
 15 [1afee1a0] (00/02) No matches
Offsetted by 112:
 01 [6acb9de4] (02/02) Accurately ripped as in pressing(s) #1
 02 [8626201c] (02/02) Accurately ripped as in pressing(s) #1
 03 [b1a8d24c] (02/02) Accurately ripped as in pressing(s) #1
 04 [288d709d] (02/02) Accurately ripped as in pressing(s) #1
 05 [a7e04b1d] (02/02) Accurately ripped as in pressing(s) #1
 06 [68298e0f] (02/02) Accurately ripped as in pressing(s) #1
 07 [ebf33def] (02/02) Accurately ripped as in pressing(s) #1
 08 [9bf87c1b] (02/02) Accurately ripped as in pressing(s) #1
 09 [fca36a15] (02/02) Accurately ripped as in pressing(s) #1
 10 [0bc6dffb] (02/02) Accurately ripped as in pressing(s) #1
 11 [4db39ee9] (02/02) Accurately ripped as in pressing(s) #1
 12 [6b5f77af] (02/02) Accurately ripped as in pressing(s) #1
 13 [0f0a5387] (02/02) Accurately ripped as in pressing(s) #1
 14 [45d75600] (02/02) Accurately ripped as in pressing(s) #1
 15 [2f2fae7b] (02/02) Accurately ripped as in pressing(s) #1

How is this possible? If I go and check offets page (http://www.accuraterip.com/driveoffsets.htm), it's clear that offset for "YAMAHA - CRW2100E"    +733. Yet, accuraterip shows "Offsetted by 112" having confidence level 2?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2008-10-11 23:41:43
How is this possible?

Quote

...
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

No errors occurred

End of status report


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: yury_usa on 2008-10-12 00:42:58
Fandango
So this pressing is different by an offset value of 112? 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2008-10-12 00:45:50
Fandango
So this pressing is different by an offset value of 112? 

Yes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-12 15:29:34
While I'm at it, could you please add support to transfer tags while encoding ? I need to transfer APE tags to FLACs.

Thanks in advance.

N.


If your APE files have tags, i suppose they have embedded CUE sheets too?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2008-10-12 15:54:13
I created a mockup to demonstrate my suggestion:

(http://i238.photobucket.com/albums/ff132/alexb2k/HA/extfix.png)

This kind of UI would allow any target extension. The tool would not require internal support for the compression format so it could be used when the audio files are converted outside CUETools. For instance, MP3 would be possible.

EDIT

It would be even better if it could optionally create a new cue file in the same location and preserve the original file.

It could add the target extension in the new filename. For example, .cue could be changed to .mp3.cue (I use this naming system).

Personally, I always do a "copy, paste & rename" procedure before I change the extensions inside a cue file. It is a time consuming step if I have a lot of cue files to edit.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-12 16:33:43

While I'm at it, could you please add support to transfer tags while encoding ? I need to transfer APE tags to FLACs.

Thanks in advance.

N.


If your APE files have tags, i suppose they have embedded CUE sheets too?


Nope, just a single-album APE file, with APEv2 tags and a separate CUE file. Maybe it's a good idea to code a wrapper for Case's/Synthetic soul's tag.exe, since it's freeware and already does what we need.

http://www.synthetic-soul.co.uk/tag/ (http://www.synthetic-soul.co.uk/tag/)

Thanks in advance,

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Moitah on 2008-10-12 19:47:48
I thought this was pretty cool, it runs fine with Mono 2.0 in Ubuntu when compiled with only WAV support:

(http://www.moitah.net/misc/CUEToolsMono.png)

Too bad Mono doesn't support C++/CLI.  There was some work on an extension for GCC to allow this but it looks like it's been abandoned.  I wonder if P/Invoking into libFLAC (for example) would work...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-12 23:32:08
I thought this was pretty cool, it runs fine with Mono 2.0 in Ubuntu when compiled with only WAV support:

Too bad Mono doesn't support C++/CLI.  There was some work on an extension for GCC to allow this but it looks like it's been abandoned.  I wonder if P/Invoking into libFLAC (for example) would work...


Cool. And i've been playing with x64 build.
Got .APE files to decompress 25% faster.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-12 23:45:17
Cool. And i've been playing with x64 build.
Got .APE files to decompress 25% faster.


Great news. Can't wait.



N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-13 05:03:17
Update: some bugs were fixed, fresher build can be found in the first post in this thread.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-13 12:30:49
Gregory, when converting from single APE to single FLAC not all the tag fields are preserved.

So far I can confirm that the YEAR tag isn't being copied to the FLAC file.

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-13 12:54:26
Also I see that you're embedding the LOG file in the tag as well.

Can you please make this (CUE & LOG tag embedding) optional ?

thanks,

N.

EDIT: Can you please make the following REM comments optional as well ?

REM ACCURATERIPID 0041d512-049e93aa-7510e519
REM DATE "2005"
REM GENRE "Rock"

I'd like to keep my CUE sheets untouched please.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-13 13:51:19
Gregory, when converting from single APE to single FLAC not all the tag fields are preserved.

So far I can confirm that the YEAR tag isn't being copied to the FLAC file.

N.


Just tested it, for me the YEAR tag was copied, but foobar2k only showed it in a properties window - it seems to expect DATE tag in flacs instead.
Update: confirmed, checked out the utility you mentioned - it has a dictionary of tag names for different formats, e.g. YEAR becomes DATE in flac. Will have to think what to do with this

Also I see that you're embedding the LOG file in the tag as well.

Can you please make this (CUE & LOG tag embedding) optional ?

thanks,

N.

EDIT: Can you please make the following REM comments optional as well ?

REM ACCURATERIPID 0041d512-049e93aa-7510e519
REM DATE "2005"
REM GENRE "Rock"

I'd like to keep my CUE sheets untouched please.


CUE embedding IS optional. It is selected by CUE style. Choose "Single file + CUE" and there won't be any embedded CUE. As for the the rest, i sure will make it optional.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Caleb on 2008-10-13 14:54:58
Hey,

Great job on a great utility!

Does this version work properly with UTF-8 encoded .CUE sheets? In 1.9.1, when creating Gaps Appended output, the filenames would be empty (or only contain the ASCII-valid chars from the unicode name, such as digits).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2008-10-13 15:18:47
I converted a "tagged APE disc image + CUE" album to FLAC + CUE with the test build.

The last character of each FLAC tag value seems to be missing. In addition, the Replay Gain tags are missing from the FLAC file and from the resulting cue file (I had foobar-generated Replay Gain tags in both source files).

I had a small cover art image embedded in the APE tags, but I didn't actually expect it to be included in the resulting FLAC tags. I just wanted to check if it would cause any problems

The APE/Year tag should indeed be mapped with the FLAC/Date tag. This is a commonly used mapping in various programs.

Tags from foobar's properties window:

Before, APE
Code: [Select]
Artist Name : Brahms / Mozart
Track Title : CDA disc image file
Album Title : Brahms Violin Concerto op.77 & Mozart Sinfonia Concertante K364 - CD
Date : 1992
Genre : Classical
Composer : Johannes Brahms (1833-1897) / Wolfgang Amadeus Mozart (1756-1791)
Performer : David Oistrakh (violin) / Igor Oistrakh (violin)
Album Artist :
Track Number :
Total Tracks :
Disc Number :
Total Discs :
Comment : recorded 1961/1972, digital mastering 1987/1985
<BAND> : Orchestre de la Radiodiffusion Française / Berliner Philharmoniker
<CONDUCTOR> : Otto Klemperer (1885-1973) / David Oistrakh (1908-1974)
After, FLAC
Code: [Select]
Artist Name : Brahms / Mozar
Track Title : CDA disc image fil
Album Title : Brahms Violin Concerto op.77 & Mozart Sinfonia Concertante K364 - C
Date :
Genre : Classica
Composer : Johannes Brahms (1833-1897) / Wolfgang Amadeus Mozart (1756-1791
Performer : David Oistrakh (violin) / Igor Oistrakh (violin
Album Artist :
Track Number :
Total Tracks :
Disc Number :
Total Discs :
Comment : recorded 1961/1972, digital mastering 1987/198
<ACCURATERIPID> : 0013e178-0065ffe0-66110306
<BAND> : Orchestre de la Radiodiffusion Française / Berliner Philharmonike
<CONDUCTOR> : Otto Klemperer (1885-1973) / David Oistrakh (1908-1974
<YEAR> : 199

I had CUETools set to write a single flac file + cue.


BTW, what do you think about this report (it's from the same album):

Code: [Select]
[Disc ID: 0013e178-0065ffe0-66110306]
Offset applied: 12
Track [ CRC    ] Status
 01 [7360d325] (05/07) Accurately ripped as in pressing(s) #1
 02 [b83ac04f] (05/07) Accurately ripped as in pressing(s) #1
 03 [9b0b3625] (05/07) Accurately ripped as in pressing(s) #1
 04 [3ecc3c43] (05/07) Accurately ripped as in pressing(s) #1
 05 [f6f8c346] (05/07) Accurately ripped as in pressing(s) #1
 06 [43f25293] (04/06) Partial match to pressing(s) #1
Offsetted by 132:
 01 [a0931b75] (02/07) Accurately ripped as in pressing(s) #2
 02 [bcb2d807] (02/07) Accurately ripped as in pressing(s) #2
 03 [892d4085] (02/07) Accurately ripped as in pressing(s) #2
 04 [70564d0b] (02/07) Accurately ripped as in pressing(s) #2
 05 [79402bf6] (02/07) Accurately ripped as in pressing(s) #2
 06 [eb129bb1] (02/06) Partial match to pressing(s) #2
What does "partial match" mean?


I attached a sample of my APE tags and the source CUE file so that you can reproduce the tagging behavior. I copied the APE tags to an APL file with MP3tag. You can do the reverse. My APE disc image file is 72 minutes 35 seconds (if you want to use a "dummy" file with about the same duration).

[attachment=4702:attachment]

EDIT: fixed a typo & a problem with the attachment.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2008-10-13 16:39:10
*) improved Filename Corrector: looks for extension change first.

Thanks! The changed Filename Corrector seems to work as described. I tested it with a bunch of "disc image + cue" albums that were in a single folder.

I think it can now help Marre with his/her problem: http://www.hydrogenaudio.org/forums/index....showtopic=66438 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66438)

Though, it cannot write a user defined filename extension independtly of the possibly existing audio file or preserve the original cue file as I suggested. In addition, it might not work as expected if the folder contains similarly named audio files in more than one format. I hope you can revisit this tool at some later time.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-13 17:23:28
I converted a "tagged APE disc image + CUE" album to FLAC + CUE with the test build.

The last character of each FLAC tag value seems to be missing. In addition, the Replay Gain tags are missing from the FLAC file and from the resulting cue file (I had foobar-generated Replay Gain tags in both source files).

I had a small cover art image embedded in the APE tags, but I didn't actually expect it to be included in the resulting FLAC tags. I just wanted to check if it would cause any problems

The APE/Year tag should indeed be mapped with the FLAC/Date tag. This is a commonly used mapping in various programs.

BTW, what do you think about this report (it's from the same album):

06   [43f25293] (04/06) Partial match to pressing(s) #1
What does "partial match" mean?


Thanks for detailed report, i fixed the problem with missing last characters, and implemented Year=>Date mapping, will post updated version soon.

ReplainGain removal was implemented by Moitah long ago, i can only guess what was the reason - probably, because when cutting/splitting/offsetting an image, those tags need to be recalculated anyway. I will wait for comments from the author before changing it.

Partial match means in fact inaccurate rip. CRCs for the whole track don't match. The only difference between "partial match" and "no matches" is that a CRC for a segment of the file that is used for offset detection does match. That means, that the problem with this track is not in offset or some kind of normalization applied, but that it most probably is just damaged. Suggestions for a more informative format for this log entry are welcomed.

As for enhanced Filename corrector, maybe i will look into it later, in it's current state it should be working for most cases. I think i should finish with tags and x64 port first.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-13 17:42:33
Hey,

Great job on a great utility!

Does this version work properly with UTF-8 encoded .CUE sheets? In 1.9.1, when creating Gaps Appended output, the filenames would be empty (or only contain the ASCII-valid chars from the unicode name, such as digits).


I guess nothing changed in that area. How do you get an UTF-8 encoded .cue sheet? Which software produces them, and which software can read them?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: yury_usa on 2008-10-14 03:25:51
Ok, how is this possible, then?

Code: [Select]
EAC extraction logfile from 20. March 2008, 21:35 for CD
Bonnie Raitt / Luck of the Draw [DCC GOLD]

Used drive  : PIONEER DVD-RW  DVR-112D  Adapter: 1  ID: 0
Read mode  : Secure with NO C2, accurate stream, disable cache
Read offset correction : 48
Overread into Lead-In and Lead-Out : No

Used output format : C:\Program Files\FLAC\flac.exe  (User Defined Encoder)
                    768 kBit/s
                    Additional command line options : -V -8 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s

Other options      :
    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    Installed external ASPI interface


Track  1
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\01 - Something To Talk About.wav

    Pre-gap length  0:00:02.00

    Peak level 96.6 %
    Track quality 100.0 %
    Test CRC F2E17BF2
    Copy CRC F2E17BF2
    Copy OK

Track  2
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\02 - Good Man, Good Woman.wav

    Pre-gap length  0:00:03.50

    Peak level 96.9 %
    Track quality 100.0 %
    Test CRC C88FFDC8
    Copy CRC C88FFDC8
    Copy OK

Track  3
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\03 - I Can't Make You Love Me.wav

    Pre-gap length  0:00:03.24

    Peak level 79.3 %
    Track quality 100.0 %
    Test CRC C1F15CAC
    Copy CRC C1F15CAC
    Copy OK

Track  4
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\04 - Tangled And Dark.wav

    Pre-gap length  0:00:02.02

    Peak level 96.9 %
    Track quality 100.0 %
    Test CRC D31D12F1
    Copy CRC D31D12F1
    Copy OK

Track  5
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\05 - Come To Me.wav

    Pre-gap length  0:00:02.70

    Peak level 98.1 %
    Track quality 99.3 %
    Test CRC 94229CDF
    Copy CRC 94229CDF
    Copy OK

Track  6
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\06 - No Business.wav

    Pre-gap length  0:00:02.20

    Peak level 95.0 %
    Track quality 100.0 %
    Test CRC 4A642E0C
    Copy CRC 4A642E0C
    Copy OK

Track  7
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\07 - One Part Be My Lover.wav

    Pre-gap length  0:00:02.34

    Peak level 55.8 %
    Track quality 100.0 %
    Test CRC 00BACFD9
    Copy CRC 00BACFD9
    Copy OK

Track  8
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\08 - Not The Only One.wav

    Pre-gap length  0:00:02.92

    Peak level 96.7 %
    Track quality 100.0 %
    Test CRC 7ED4DA66
    Copy CRC 7ED4DA66
    Copy OK

Track  9
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\09 - Papa Come Quick (Jody And Chico).wav

    Pre-gap length  0:00:02.88

    Peak level 74.4 %
    Track quality 100.0 %
    Test CRC 2A962E12
    Copy CRC 2A962E12
    Copy OK

Track 10
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\10 - Slow Ride.wav

    Pre-gap length  0:00:01.98

    Peak level 96.7 %
    Track quality 99.9 %
    Test CRC 4E6AE459
    Copy CRC 4E6AE459
    Copy OK

Track 11
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\11 - Luck Of The Draw.wav

    Pre-gap length  0:00:03.77

    Peak level 96.7 %
    Track quality 100.0 %
    Test CRC 7AAB6005
    Copy CRC 7AAB6005
    Copy OK

Track 12
    Filename C:\Bonnie Raitt - Luck of the Draw (1997) [FLAC] {DCC Gold GZS-1107}\12 - All At Once.wav

    Pre-gap length  0:00:03.09

    Peak level 70.3 %
    Track quality 100.0 %
    Test CRC 365DBD56
    Copy CRC 365DBD56
    Copy OK

No errors occured


End of status report

Code: [Select]
CDImage.cue:

Checking AccurateRip database

URL: [url=http://www.accuraterip.com/accuraterip/2/4/6/dBAR-012-0017b642-00de56e3-970ca30c.bin]http://www.accuraterip.com/accuraterip/2/4...e3-970ca30c.bin[/url]
Track Ripping Status [Disc ID: 0017b642-970ca30c]

 1 ** Rip not accurate **  (confidence 6)    [cc271ecd] [4cc86965]
 2 ** Rip not accurate **  (confidence 5)    [1b26ea83] [89f51ecb]
 3 ** Rip not accurate **  (confidence 5)    [a87b86bf] [247023fe]
 4 ** Rip not accurate **  (confidence 5)    [cb704a3b] [e51f72a6]
 5 ** Rip not accurate **  (confidence 5)    [b336a534] [b86f4ed1]
 6 ** Rip not accurate **  (confidence 5)    [a6478b08] [106898ba]
 7 ** Rip not accurate **  (confidence 5)    [19acf21d] [a845e452]
 8 ** Rip not accurate **  (confidence 5)    [47681b62] [89087cb5]
 9 ** Rip not accurate **  (confidence 5)    [39e53f91] [a3844d50]
 10 ** Rip not accurate **  (confidence 5)    [605ef9f6] [de287f36]
 11 ** Rip not accurate **  (confidence 5)    [e817d4b0] [8083dbf7]
 12 ** Rip not accurate **  (confidence 5)    [f8bee495] [a8fd1658]

_______________________

Your CD disc is possibly a different pressing to the one(s) stored in AccurateRip.
Track(s) Accurately Ripped: 0
**** Track(s) Not Ripped Accurately: 12 ****
Track(s) Not in Database: 0

CueTools 1.9.2 told me this after "fixing":

Code: [Select]
Offset applied: 618
[Disc ID: 0017b642-00de56e3-970ca30c]
Track [ CRC    ] Status
 01 [cc271ecd] (06/06) Accurately ripped as in pressing(s) #1
 02 [1b26ea83] (05/05) Accurately ripped as in pressing(s) #1
 03 [a87b86bf] (05/05) Accurately ripped as in pressing(s) #1
 04 [cb704a3b] (05/05) Accurately ripped as in pressing(s) #1
 05 [b336a534] (05/05) Accurately ripped as in pressing(s) #1
 06 [a6478b08] (05/05) Accurately ripped as in pressing(s) #1
 07 [19acf21d] (05/05) Accurately ripped as in pressing(s) #1
 08 [47681b62] (05/05) Accurately ripped as in pressing(s) #1
 09 [39e53f91] (05/05) Accurately ripped as in pressing(s) #1
 10 [605ef9f6] (05/05) Accurately ripped as in pressing(s) #1
 11 [e817d4b0] (05/05) Accurately ripped as in pressing(s) #1
 12 [f8bee495] (05/05) Accurately ripped as in pressing(s) #1
Now, freeDB clearly recognizes the new wav as "DCC Gold", so it is the same pressing. Why for a properly made log with correct offset value (yes, 48 is correct for this drive), I still do not get a perfect match?

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Quote changed to codebox.  Please learn how to use this feature.[/size]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2008-10-14 03:29:35
Now, freeDB clearly recognizes the new wav as "DCC Gold", so it is the same pressing.

Just because freeDB recognizes it doesn't mean it's the same pressing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: yury_usa on 2008-10-14 18:47:12
Would it be possible to generate AccurateRip report after pressing the "convert" button? I believe this was implemented in earlier builds, and now it's gone (?)
That way I don't have to go through the procedure twice by verifying the generated CUE from "New" directory
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-14 19:30:50
Would it be possible to generate AccurateRip report after pressing the "convert" button? I believe this was implemented in earlier builds, and now it's gone (?)
That way I don't have to go through the procedure twice by verifying the generated CUE from "New" directory

Use the "Verify, then encode" mode.
Make sure that "Encode only if" and "Fix offset if" in advanced settings are turned off, if you want it to always convert without offset correction.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: naturfreak on 2008-10-14 22:07:01
Thanks for this useful tool.

A small feature request.
Show a message when a cuesheet contains tracks with pre-emphasis (Line 'FLAGS PRE')
I think that would be useful as a reminder to de-emphase the tracks created by the program.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-15 06:06:02
Gregory,

Update5 is working fine. Got a couple of comments for you..

1) In batch mode, please add an option to force overwrite when a file exists. Since I'm converting properly named/tagged APE+CUE Image files to FLAC+CUE, the original CUE file is always overwriten with the new CUE, so I always get the "some files will get overwriten" dialog, thus defeating the purpose of batch mode.

2) glad to see the Year/Date tag mapping. I hope you can make the REM comments on the CUE sheet optional for the next release as well.

3) How about a Pause button for Batch mode ?

4) I suggest the Convert button be renamed to Process or Execute or something more generic, don't you think ?

Thanks for receiving and taking into account our input. I really appreciate it.

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Caleb on 2008-10-15 09:58:11

Hey,

Great job on a great utility!

Does this version work properly with UTF-8 encoded .CUE sheets? In 1.9.1, when creating Gaps Appended output, the filenames would be empty (or only contain the ASCII-valid chars from the unicode name, such as digits).


I guess nothing changed in that area. How do you get an UTF-8 encoded .cue sheet? Which software produces them, and which software can read them?


Hi Gregory,

Well I have a few albums by the Russian bands DDT and Mashina Vremeni, and they are both ripped as one whole FLAC + CUE, so I wanted to split them. Unfortunately the CUE was OEM ASCII (the extended character set), and since my locale was different I decided to manually edit the CUE in Notepad to change the track/album/artist names to proper Russian.

Now I want to split the FLAC but CueTools doesn't like it
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2008-10-16 19:14:28

However, what would be great would be if CUETools could still be able to give an AccurateRip confidence score for tracks 01-12 that have been perfectly ripped...  Ideally it should skip track 14, say that tracks 01-12 are accurate, track 13 isn't (since it has been splitted), and track 14 is unknown for this album.


Unfortunately, this is impossible. You have to know the id of the disk to be able to compare it to the database, and diskId depends on the number and length of the tracks. So if you split a track, cut out silence - there's no way to tell which disk it is that you have.


Oh well, it might be:

(1) If you use one-folder-per-album and the files are tagged with original tracknumber, then they may be concatenated to a single file and cue sheet generated.
Since AccurateRip is tracks based, it would of course be much easier to scan folder for .flac (or .ape or whatever), extract from the metadata the information you would usually extract from the cue sheet, and contact the AR base. Even if there is no tracknumber tag (they sometimes appear as "4/14" or just "4"), it should be easy to specify a en extraction of number from a filename pattern, like implemented in some tag-from-filename features.
So if one track is split into two files, what you need is to have a Totaltracks tag equal to the original total tracks of the CD. With 14 enumerated files of an original Totaltracks=13, the "fourteenth file" could be track 1 split in 1&2, 2 split in 2&3 etc., 13 possibilities. If you encounter such a folder, prompt the user to specify which files to join.
(Are there other uses for the Totaltracks tag? Will an audio player object if you add a file with Tracknumber = 14 and Totaltracks = 13?)

(2) dBpoweramp writes the AccurateRipDiscID as a Vorbis comment in my flac files. Don't know about other file formats though.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-16 20:47:27
(1) If you use one-folder-per-album and the files are tagged with original tracknumber, then they may be concatenated to a single file and cue sheet generated.
Since AccurateRip is tracks based, it would of course be much easier to scan folder for .flac (or .ape or whatever), extract from the metadata the information you would usually extract from the cue sheet, and contact the AR base. Even if there is no tracknumber tag (they sometimes appear as "4/14" or just "4"), it should be easy to specify a en extraction of number from a filename pattern, like implemented in some tag-from-filename features.
So if one track is split into two files, what you need is to have a Totaltracks tag equal to the original total tracks of the CD. With 14 enumerated files of an original Totaltracks=13, the "fourteenth file" could be track 1 split in 1&2, 2 split in 2&3 etc., 13 possibilities. If you encounter such a folder, prompt the user to specify which files to join.
(Are there other uses for the Totaltracks tag? Will an audio player object if you add a file with Tracknumber = 14 and Totaltracks = 13?)

(2) dBpoweramp writes the AccurateRipDiscID as a Vorbis comment in my flac files. Don't know about other file formats though.


(1) Thanks for interstring thoughts on the matter. There are no other uses for totaltracks, but this tag is often absent. Luckily enough, total number of tracks can be also extracted from cddb DISCID tag.

But i'm still quite pessimistic about the possibility of recovering an album structure, when tracks were split. Ok, we can sacrifice that split track and focus on verifying other tracks, but for that we have to know for sure it's length. And it will not be a sum of it's parts in most cases. The silent gaps would most probably be left out - for example, in the mentioned case the track was split because in contained a 'hidden' track. 'Hidden' means there was probably some lengthy silence before it, and i doubt that people would keep that silent gap when editing the track. And even if they did, most audio software would not try to preserve CD sector boundaries when splitting - it would be split in arbitary point, and padded for encoding.

Summarising, i doubt any such algorithm would be able to verify the majority of disc images after such treatment. And most people don't do such things to their rips, so i'm probably not going to invest too much time in further studies of this problem.

(2) Oops. I didn't know that. CueTools uses "ACCURATERIPID" tag. I guess i'll have to rename it to make it compatible. Is "AccurateRipDiscID" the exact name of the tag?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-16 21:30:41
1) In batch mode, please add an option to force overwrite when a file exists. Since I'm converting properly named/tagged APE+CUE Image files to FLAC+CUE, the original CUE file is always overwriten with the new CUE, so I always get the "some files will get overwriten" dialog, thus defeating the purpose of batch mode.


This i think is not a good idea. People might turn this option on by mistake and destroy their original files when they didn't want to.

I would just use the "Append to filename" option, set it to for example ".flac". That would make "Artist - Album.cue" saved as "Artist - Album.flac.cue. If this doesn't sound reasonable, you can use "Create subdirectory" option and move all the files back after successfull conversion, if you are happy with the results.

As for the rest, i'm working on it
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2008-10-17 01:06:14
(2) Oops. I didn't know that. CueTools uses "ACCURATERIPID" tag. I guess i'll have to rename it to make it compatible. Is "AccurateRipDiscID" the exact name of the tag?


Yep: dBpoweramp provides tags like the following (cut and pasted from metaflac output of two tracks from two different CDs):


AccurateRipResult=AccurateRip: Not in database  Secure: Yes  [3B3B1D60]
AccurateRipDiscID=002-0000bd74-0001fa28-0901b202-1

(track 1 of 2)


AccurateRipDiscID=018-0034a011-02b34812-18120f12-15
AccurateRipResult=AccurateRip: Accurate (confidence 10)  [BFD8DBAE]

(track 15 of 18).



As for (1), it is of course more important to have an application working for those of us who use one-file-per-track than for user-created splits.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-17 19:13:59
Hi Gregory,

Well I have a few albums by the Russian bands DDT and Mashina Vremeni, and they are both ripped as one whole FLAC + CUE, so I wanted to split them. Unfortunately the CUE was OEM ASCII (the extended character set), and since my locale was different I decided to manually edit the CUE in Notepad to change the track/album/artist names to proper Russian.

Now I want to split the FLAC but CueTools doesn't like it


Try the updated version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-18 01:43:56
Hi Gregory !

here's my report on Update 6.

1) MonkeysAudio input doesn't work for me. Tried it both in batch and single mode. For the record, all my APEs are v3.97 (high), with APETagv2.

2) Glad to see you added APE output, just for completness sake. As you already know I'm moving away from that dying format, but that's another story.  I'm sure you're an update away from adding APE compression settings as well.

3) On the main window, I suggest you use a checkbox to enable/disable the Accuraterip groupbox (maybe beside the Accurate rip label) and then drop the option "don't verify, encode" leaving just 2 options: 1) Verify, then Encode and 2) Only Verify. I think it's cleaner this way, don't you agree ? Nitpicking... I know.

4) Using the same AccurateRip tag as dbPoweramp is a really good idea, just for standards sake. dbPoweamp is spoon's project as well, so it makes sense to stick with his terminology.

5) maybe you can implement a file compare function, similar to shntool's cmp function. This way you can compare the WAV data from different formats after transcoding, to make sure they're identical (which is the whole point of all this lossless manipulation, right ?).

As you might have noticed, almost all of my suggestions work towards developing a new powerful tool that can be used to batch transcode lossless formats in a simple, automated and most importantly, confident way. This is specially true for files that don't verify in AR, but you'd like to trasncode anyway, making sure you still have a bitperfect wav underneath. Right now there isn't a tool that can do this easily. The new functionalities you added to CUETools show great potential to fullfill this type of app requirements.

Please, keep on the excelent work !

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2008-10-18 15:20:51
Feature request: duplicates detection. For "duplicates modulo offset", of course.

I would guess that at least the following three levels of detection could be useful.

Level 1: track-based offset adjustment; keep the intermediate values and flac pairs of albums with 100% match for a certain offset. (Better, even: "tolerate n exceptions".)
Level 2: check with either cuesheet's data in order to adjust for gap prepended/gap appended


As for the Level 1 thing, just consider the two below output files -- the two AR entries of a single CD. Had there been an an option to report in a format where the results are given in the order of the pressings and the offset value was omitted, I could simply fire up my usual clonefile-finder.

Code: [Select]
[Disc ID: 000e94fa-0076ba4d-7109720a]
Track [ CRC    ] Status
 01 [3f9f2536] (06/11) Accurately ripped as in pressing(s) #2
 02 [99ae9eb8] (06/11) Accurately ripped as in pressing(s) #2
 03 [07bb4408] (06/11) Accurately ripped as in pressing(s) #2
 04 [ce599629] (06/11) Accurately ripped as in pressing(s) #2
 05 [33ffebc8] (06/11) Accurately ripped as in pressing(s) #2
 06 [5e178c32] (06/10) Accurately ripped as in pressing(s) #2
 07 [4f07e19d] (06/10) Accurately ripped as in pressing(s) #2
 08 [b72ec0c9] (06/10) Accurately ripped as in pressing(s) #2
 09 [22050f8c] (06/10) Accurately ripped as in pressing(s) #2
 10 [a4febe92] (06/10) Accurately ripped as in pressing(s) #2
Offsetted by 561:
 01 [fa31d585] (05/11) Accurately ripped as in pressing(s) #1
 02 [5fa2c624] (05/11) Accurately ripped as in pressing(s) #1
 03 [271f9ac7] (05/11) Accurately ripped as in pressing(s) #1
 04 [c4df97b2] (05/11) Accurately ripped as in pressing(s) #1
 05 [87152f19] (05/11) Accurately ripped as in pressing(s) #1
 06 [ea47ae5f] (04/10) Accurately ripped as in pressing(s) #1
 07 [453db693] (04/10) Accurately ripped as in pressing(s) #1
 08 [17ce39b4] (04/10) Accurately ripped as in pressing(s) #1
 09 [1cef54bf] (04/10) Accurately ripped as in pressing(s) #1
 10 [8ed9836f] (04/10) Accurately ripped as in pressing(s) #1

and

Code: [Select]
[Disc ID: 000e94fa-0076ba4d-7109720a]
Track [ CRC    ] Status
 01 [fa31d585] (05/11) Accurately ripped as in pressing(s) #1
 02 [5fa2c624] (05/11) Accurately ripped as in pressing(s) #1
 03 [271f9ac7] (05/11) Accurately ripped as in pressing(s) #1
 04 [c4df97b2] (05/11) Accurately ripped as in pressing(s) #1
 05 [87152f19] (05/11) Accurately ripped as in pressing(s) #1
 06 [ea47ae5f] (04/10) Accurately ripped as in pressing(s) #1
 07 [453db693] (04/10) Accurately ripped as in pressing(s) #1
 08 [17ce39b4] (04/10) Accurately ripped as in pressing(s) #1
 09 [1cef54bf] (04/10) Accurately ripped as in pressing(s) #1
 10 [8ed9836f] (04/10) Accurately ripped as in pressing(s) #1
Offsetted by -561:
 01 [3f9f2536] (06/11) Accurately ripped as in pressing(s) #2
 02 [99ae9eb8] (06/11) Accurately ripped as in pressing(s) #2
 03 [07bb4408] (06/11) Accurately ripped as in pressing(s) #2
 04 [ce599629] (06/11) Accurately ripped as in pressing(s) #2
 05 [33ffebc8] (06/11) Accurately ripped as in pressing(s) #2
 06 [5e178c32] (06/10) Accurately ripped as in pressing(s) #2
 07 [4f07e19d] (06/10) Accurately ripped as in pressing(s) #2
 08 [b72ec0c9] (06/10) Accurately ripped as in pressing(s) #2
 09 [22050f8c] (06/10) Accurately ripped as in pressing(s) #2
 10 [a4febe92] (06/10) Accurately ripped as in pressing(s) #2
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-19 00:29:42
Hi Gregory !

here's my report on Update 6.

1) MonkeysAudio input doesn't work for me. Tried it both in batch and single mode. For the record, all my APEs are v3.97 (high), with APETagv2.


Oops, upon revisiting this thread I noticed that I ommited to disclose what error msg I've been receiving. CUETools says it cannot access the .ape file because it is being used by another process. Of course this isn't true, as I've tested with several files and made sure there where no open handlers associated to them.

Thanks,

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-19 03:02:59
Oops, upon revisiting this thread I noticed that I ommited to disclose what error msg I've been receiving. CUETools says it cannot access the .ape file because it is being used by another process. Of course this isn't true, as I've tested with several files and made sure there where no open handlers associated to them.

Thanks. Was going to ask that question.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-10-19 09:41:06
Just wanted to let people know that the "CUE Tools has encountered a problem and needs to close." messages can be caused by running it over a (in my case Samba) network share. Copy it to the C drive to run it and it will work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-10-19 09:53:52
Accurite rip reports the offset is wrong. I found out the correct offset is 30 so I put that in cueTOOLs and this is what I get:

[Disc ID: 000da5b7-00503621-540c9507]
Offset applied: 30
Track   [ CRC    ] Status
01   [2f18d0b0] (00/21) No matches
02   [a5c42498] (00/20) No matches
03   [d6c392c0] (00/21) No matches
04   [be3c27f3] (00/20) No matches
05   [441afd21] (00/20) No matches
06   [3cf8b0f2] (00/20) No matches
07   [4d636851] (00/20) No matches
Offsetted by 0:
01   [723f191a] (02/21) Accurately ripped as in pressing(s) #2
02   [01371491] (02/20) Accurately ripped as in pressing(s) #2
03   [dc2422c5] (02/21) Accurately ripped as in pressing(s) #2
04   [7b653671] (02/20) Accurately ripped as in pressing(s) #2
05   [7f3c7239] (02/20) Accurately ripped as in pressing(s) #2
06   [58b39608] (02/20) Accurately ripped as in pressing(s) #2
07   [ca758367] (02/20) Accurately ripped as in pressing(s) #2

I'm not sure I get the logic. However I can set the offset to 0 and get the report in 1.9.2, and then put the offset into 1.9.1 and apply it there.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-10-19 11:45:09
I thought this was pretty cool, it runs fine with Mono 2.0 in Ubuntu when compiled with only WAV support:

Too bad Mono doesn't support C++/CLI.  There was some work on an extension for GCC to allow this but it looks like it's been abandoned.  I wonder if P/Invoking into libFLAC (for example) would work...



Wow, how would I get a copy with only wav support? I'm already converting to FLAC in a bash script as I'm not interested in encoding in a VM and Windows is way too time consuming to keep all the codecs up to date anyway. A CLI version would be the ultimate... I've slowly been working on something similar as far as calculating the correct offset.. I got as far as correctly calculating the Diskids and submitting the request and receiving the track checksums. I have no clue how you're detecting the different pressings, AccurateRip only gives back the track checksum and confidence score.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Caleb on 2008-10-19 12:28:37

Hi Gregory,

Well I have a few albums by the Russian bands DDT and Mashina Vremeni, and they are both ripped as one whole FLAC + CUE, so I wanted to split them. Unfortunately the CUE was OEM ASCII (the extended character set), and since my locale was different I decided to manually edit the CUE in Notepad to change the track/album/artist names to proper Russian.

Now I want to split the FLAC but CueTools doesn't like it


Try the updated version.


I tried the new version, and the filename of the first track was "01 - __________ ____.flac".
It's better than the previous version, which created a file like "01 - .flac", but still not quite right!

The CUE looks like this:
Code: [Select]
REM GENRE Rock
REM DATE 1982
REM COMMENT YEAR: 2001 ID3G: 17
PERFORMER "???"
TITLE "?????? ?? ??????"
FILE "??? - ?????? ?? ?????? ( ??????????? XXI ???, ??????? ????? ?????????? ).flac" WAVE
  TRACK 01 AUDIO
    TITLE "?????????? ????"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "?? 50 ??????"
    INDEX 00 04:07:04
    INDEX 01 04:07:09
  TRACK 03 AUDIO
    TITLE "??????????? ????"
    INDEX 00 06:28:06
    INDEX 01 06:30:04
  TRACK 04 AUDIO
    TITLE "????"
    INDEX 00 09:56:29
    INDEX 01 09:58:34
  TRACK 05 AUDIO
    TITLE "???????"
    INDEX 00 18:05:22
    INDEX 01 18:07:10
  TRACK 06 AUDIO
    TITLE "????"
    INDEX 00 20:20:35
    INDEX 01 20:22:03
  TRACK 07 AUDIO
    TITLE "?????? ?? ??????"
    INDEX 00 25:34:22
    INDEX 01 25:36:34
  TRACK 08 AUDIO
    TITLE "????"
    INDEX 00 28:07:52
    INDEX 01 28:10:23
  TRACK 09 AUDIO
    TITLE "???????"
    INDEX 00 31:14:62
    INDEX 01 31:17:45
  TRACK 10 AUDIO
    TITLE "?????"
    INDEX 00 36:35:73
    INDEX 01 36:38:08
  TRACK 11 AUDIO
    TITLE "?? ???????"
    INDEX 00 39:47:09
    INDEX 01 39:48:73
  TRACK 12 AUDIO
    TITLE "????"
    INDEX 00 43:30:45
    INDEX 01 43:32:57
  TRACK 13 AUDIO
    TITLE "?????????????"
    INDEX 00 47:17:11
    INDEX 01 47:18:62
  TRACK 14 AUDIO
    TITLE "?????"
    INDEX 00 48:39:48
    INDEX 01 48:42:27
  TRACK 15 AUDIO
    TITLE "??? ???? ????? ???????"
    INDEX 00 50:42:33
    INDEX 01 50:44:47
  TRACK 16 AUDIO
    TITLE "??????? ???-?????? ?????????"
    INDEX 00 54:35:37
    INDEX 01 54:39:63
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-19 12:44:48
Accurite rip reports the offset is wrong. I found out the correct offset is 30 so I put that in cueTOOLs and this is what I get:

[Disc ID: 000da5b7-00503621-540c9507]
Offset applied: 30
Track   [ CRC    ] Status
01   [2f18d0b0] (00/21) No matches
02   [a5c42498] (00/20) No matches
03   [d6c392c0] (00/21) No matches
04   [be3c27f3] (00/20) No matches
05   [441afd21] (00/20) No matches
06   [3cf8b0f2] (00/20) No matches
07   [4d636851] (00/20) No matches
Offsetted by 0:
01   [723f191a] (02/21) Accurately ripped as in pressing(s) #2
02   [01371491] (02/20) Accurately ripped as in pressing(s) #2
03   [dc2422c5] (02/21) Accurately ripped as in pressing(s) #2
04   [7b653671] (02/20) Accurately ripped as in pressing(s) #2
05   [7f3c7239] (02/20) Accurately ripped as in pressing(s) #2
06   [58b39608] (02/20) Accurately ripped as in pressing(s) #2
07   [ca758367] (02/20) Accurately ripped as in pressing(s) #2

I'm not sure I get the logic. However I can set the offset to 0 and get the report in 1.9.2, and then put the offset into 1.9.1 and apply it there.


I didn't quite get what you do to get such a log.
You run 1.9.2 in verify mode, and it tells you that your rip would be accurate offsetted by 30, right?
Then you do what? Put it in advanced settings->Write offset box and convert it to fix the offset?
And then you run verify again on the converted version?
Then you are doing wrong.

First, because you should have removed that write offset from advanced settings before verifying the converted version. Because it applies that offset again when verifying, so it tells you that 30 is a wrong offset, and it should be zero.

Second, because it all could have been done automaticly. You could turn on the 'Fix offset if' option in advanced settings, leaving 'write offset' option zero, and run CUETools in "Verify, then encode" mode. It would calculate the correct offset and immediately apply it upon conversion, you won't have to enter it manualy.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-19 14:02:12
I tried the new version, and the filename of the first track was "01 - __________ ____.flac".
It's better than the previous version, which created a file like "01 - .flac", but still not quite right!

Okay, i see where it went wrong. There's is a safety measure - filenames are encoded so that they would be accessible from non-unicode applications (e.g. FAR manager). My default locale is russian, so it worked for me just fine  I tested it on some swedish music that i have, and it worked fine too - substituting all those 'å' characters with 'a', etc. But there is no such substitution for cyrillic characters. So i guess i'll have to add another setting, to make this safety measure optional. The option would probably be called 'Make filenames ANSI-safe'. You would have to disable it in order to allow russian filenames in non-russian locale. For most users that option would be better left on.

Oh, and you will also have to disable "Remove special characters except" option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-19 14:50:34
Gregory,

I can confirm that Update7 is now working with my APEs.

Got another request for you...

Can you make CUETools  write an .accurip log even when the disc isn't found on the AR DB ?. This really helps when dealing with large batch transcoding.

Thanks.

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fredhammersmith on 2008-10-19 15:34:46
I have a question: can CueTools process hi-rez files, like 24/96?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mhudson7 on 2008-10-19 16:43:49
I love this tool!  Thanks to everybody for their time and efforts.

I can't wait for a rainy day!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Moitah on 2008-10-19 19:09:37
@Corwin: I will see about posting a WAV-only build later after I do some testing.

@fredhammersmith: No, it can't.

@Gregory: I just checked in some stuff, to support WAV-only compilation, and to fix some cosmetic issues -- control spacing, tab order, work around auto-scaling issue (e.g. users w/ 120 DPI display setting).  Feel free to change anything back if it messes you up .
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-20 06:42:03
AccurateRipDiscID=018-0034a011-02b34812-18120f12-15
AccurateRipResult=AccurateRip: Accurate (confidence 10)  [BFD8DBAE]
(track 15 of 18).


That's wierd.
So dbpoweramp puts the track number and total number of tracks in this tag.
I was thinking it's not neccecary, because the total number of tracks is stored in this ID anyway - in the last byte of cddb-id part. But in this case the cddb-id part shows there were 12 tracks: 018-0034a011-02b34812-18120f12-15
And dbpoweramp says there's 18. What could this mean? Is this a two-disc release, with 6 tracks on disc 1 and 12 tracks on disc two?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-10-20 08:25:34
Well I have a few albums by the Russian bands DDT and Mashina Vremeni, and they are both ripped as one whole FLAC + CUE, so I wanted to split them. Unfortunately the CUE was OEM ASCII (the extended character set), and since my locale was different I decided to manually edit the CUE in Notepad to change the track/album/artist names to proper Russian.


I do one of the following to convert Russian to Unicode (UTF-8)

Non ASCII file:
enca -L russian -c -x UTF-8 filename

extended ASCII:
iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile > newfile


Works good on Linux, you can probably find the same utilities compiled on Windows (or do the intelligent thing and run Linux). I believe Windows uses UTF-16 for unicode, not UTF-8

good luck

Then you are doing wrong.


You're exactly right. Thanks for your help.  It's working good now, no more OE (operator error).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2008-10-20 10:38:46
So dbpoweramp puts the track number and total number of tracks in this tag.
I was thinking it's not neccecary, because the total number of tracks is stored in this ID anyway - in the last byte of cddb-id part. But in this case the cddb-id part shows there were 12 tracks: 018-0034a011-02b34812-18120f12-15
And dbpoweramp says there's 18. What could this mean? Is this a two-disc release, with 6 tracks on disc 1 and 12 tracks on disc two?


First, CDDB-ID's "12" is hexadecimal, equal to 16 + 2 = 18 in decimal numbers.

As for the "not necessary" part, the CDDB-ID trackcount and the AccurateRipDiscID trackcount might differ if there is a data track. According to Spoon, CDs might have the data track at the beginning (what he refers to as "Playstation" type) or at the end (I think this is common with the CDEnhanced type) -- I do not know whether there are CDs with a data sessions in both ends. At least the "Playstation" type return quite inconsistent tracknumberings from metadata sources, and evidently, some ripping/tagging applications will insist on the music starting at track #1, others will insist it starts at track #2.

(Maybe they will also differ if there is a "Hidden Track One Audio", i.e. a Track 1 Index 0 of more than two seconds, I might check when I get home; Track 0 is treated as an exception in AccurateRip because a few drives cannot extract the information and would insist on returning zeroes, so am I told.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-20 11:44:05
First, CDDB-ID's "12" is hexadecimal, equal to 16 + 2 = 18 in decimal numbers.

Thanks a lot. I'm a complete idiot or i should sleep more often ^^
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2008-10-20 15:17:02

First, CDDB-ID's "12" is hexadecimal, equal to 16 + 2 = 18 in decimal numbers.

Thanks a lot. I'm a complete idiot or i should sleep more often ^^

And either way you have no time to fix it the next couple of years? 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-22 12:55:28
I tried the new version, and the filename of the first track was "01 - __________ ____.flac".
It's better than the previous version, which created a file like "01 - .flac", but still not quite right!


Check out the next update
Uncheck 'Remove special characters' and 'Force ANSI filenames'.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2008-10-22 21:56:42
Moitah and Gregory, thank you so much for CUE Tools. I have been using it quite a lot for just over two weeks and I really like this tool. I especially love the AccurateRip database support that Gregory added.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2008-10-23 01:03:08
I started using the latest Update 8 (after replacing Update 2). Now when I "Verify, don't encode", all of my FLAC files have their timestamps updated to the current time. In Update 2 this did not happen -- my FLAC files kept their original dates and times.

If I only verify my FLAC files, why do the dates and times of all those files need to be updated? I strongly prefer the previous behaviour.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-23 08:13:53
I started using the latest Update 8 (after replacing Update 2). Now when I "Verify, don't encode", all of my FLAC files have their timestamps updated to the current time. In Update 2 this did not happen -- my FLAC files kept their original dates and times.

If I only verify my FLAC files, why do the dates and times of all those files need to be updated? I strongly prefer the previous behaviour.


That's because it writes AR tags.
For now you can turn off 'write tags' option (advanced settings->accurate rip).
I'll probably split it into 'write tags on encode' and 'write tags on verify'.
Or will preserving the file modification time be enough?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2008-10-23 17:15:58
OK, thanks for the explanation, Gregory. The tooltip help for the AccurateRip "Write tags" feature says 'When using "apply offset" AccurateRip mode, also add ACCURATERIPCOUNT tag to flac files'. Since I wasn't applying any offset (only verifying), I didn't expect my FLAC files to be modified.

Preserving the file modification time would be more than enough for me (I would be very happy  ). Your ideas of 'write tags on encode' and 'write tags on verify' sound good.

Perhaps you could add an option such as Mp3tag's "Preserve file modification time when saving tags" (which I always use)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Moitah on 2008-10-23 19:12:50
IMHO even if the modified times are preserved, writing of tags during verification should be optional and disabled by default.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-23 21:20:17
IMHO even if the modified times are preserved, writing of tags during verification should be optional and disabled by default.


I totally agree with Moitah.

Gragory, Update 8 is looking good. I'm gonna test it a little further before I post my observations.

Nitpick: When Pause button is engaged, it should change the label to Resume, don't you think ?

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-25 21:14:09
Gregory,

while using the "Verify, then encode" mode with a 100% and confidence>=1 parameters, I experienced the following behaviour:

Even though the file's offset didn't match with AR's DB, it got encoded anyway.

To me, the main purpose of the "verify, then encode" mode is to make sure that all the files that actually get encoded are AR matched, and that includes the offset. For those files who don't fit this criteria, I then revisit the AR log files as well as the EAC logs to determine what is the correct offset to apply.

I suggest you change this mode behaviour.

Here's the AR log for this file.

Code: [Select]
[Disc ID: 002df116-02674f90-03113b12]
Track    [ CRC    ] Status
01    [a9f3e40d] (00/04) No matches
02    [5eae1bf4] (00/04) No matches
03    [650b5c3a] (00/04) No matches
04    [48267af0] (00/04) No matches
05    [0fc1bae8] (00/04) No matches
06    [3cda61e7] (00/04) No matches
07    [d1891d55] (00/04) No matches
08    [1b80f43f] (00/04) No matches
09    [109806eb] (00/04) No matches
10    [fd02391a] (00/04) No matches
11    [a28b572b] (00/04) No matches
12    [643e9727] (00/04) No matches
13    [2ebfc088] (00/04) No matches
14    [a2f4fb66] (00/04) No matches
15    [0aee6e38] (00/04) No matches
16    [7b83e15e] (00/04) No matches
17    [cb9d7f5f] (00/04) No matches
18    [12b39bbc] (00/04) No matches
Offsetted by 2:
01    [04269899] (04/04) Accurately ripped as in pressing(s) #1
02    [e5fa7b7b] (04/04) Accurately ripped as in pressing(s) #1
03    [1b1f6861] (04/04) Accurately ripped as in pressing(s) #1
04    [e21a4d20] (04/04) Accurately ripped as in pressing(s) #1
05    [d93d5ea8] (04/04) Accurately ripped as in pressing(s) #1
06    [2c5ab0dd] (04/04) Accurately ripped as in pressing(s) #1
07    [3f05b528] (04/04) Accurately ripped as in pressing(s) #1
08    [3c602a68] (04/04) Accurately ripped as in pressing(s) #1
09    [77e0d0cf] (04/04) Accurately ripped as in pressing(s) #1
10    [9235c9b4] (04/04) Accurately ripped as in pressing(s) #1
11    [9357b2f7] (04/04) Accurately ripped as in pressing(s) #1
12    [9ddee790] (04/04) Accurately ripped as in pressing(s) #1
13    [ae9afba9] (04/04) Accurately ripped as in pressing(s) #1
14    [4a8f4038] (04/04) Accurately ripped as in pressing(s) #1
15    [a561c27e] (04/04) Accurately ripped as in pressing(s) #1
16    [e6453dde] (04/04) Accurately ripped as in pressing(s) #1
17    [d8b5ab66] (04/04) Accurately ripped as in pressing(s) #1
18    [a1c7a011] (04/04) Accurately ripped as in pressing(s) #1


thanks in advance,

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-10-26 08:31:22
Gregory,

while using the "Verify, then encode" mode with a 100% and confidence>=1 parameters, I experienced the following behaviour:

Even though the file's offset didn't match with AR's DB, it got encoded anyway.

To me, the main purpose of the "verify, then encode" mode is to make sure that all the files that actually get encoded are AR matched, and that includes the offset. For those files who don't fit this criteria, I then revisit the AR log files as well as the EAC logs to determine what is the correct offset to apply.

I suggest you change this mode behaviour.

thanks in advance,

N.


Well, it's functioning as designed. It was made for those users, who don't want to fix offsets.
Also you could use it in conjunction with 'fix offset if' option to automaticly fix offsets.
If you insist on manual offset correction, well, i can add another option to that 'convert only if' block: 'convert only if 100% tracks match with condidence >= 1 and zero offset'.
I'm only worrying that soon that options window will be so huge it won't fit on screen
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-10-26 13:32:40

Gregory,

while using the "Verify, then encode" mode with a 100% and confidence>=1 parameters, I experienced the following behaviour:

Even though the file's offset didn't match with AR's DB, it got encoded anyway.

To me, the main purpose of the "verify, then encode" mode is to make sure that all the files that actually get encoded are AR matched, and that includes the offset. For those files who don't fit this criteria, I then revisit the AR log files as well as the EAC logs to determine what is the correct offset to apply.

I suggest you change this mode behaviour.

thanks in advance,

N.




Well, it's functioning as designed. It was made for those users, who don't want to fix offsets.
Also you could use it in conjunction with 'fix offset if' option to automaticly fix offsets.
If you insist on manual offset correction, well, i can add another option to that 'convert only if' block: 'convert only if 100% tracks match with condidence >= 1 and zero offset'.
I'm only worrying that soon that options window will be so huge it won't fit on screen


Well it's not my intention to have a new mode added, because as you pointed out, it will quickly get out of control. What I'm after is maybe an advanced option that can be enabled that may be named something like "Don't consider aditional offsets for AR verification". Obviously this switch should be tied only to the "Encode only if" option.

I also have another bug report for you.

Check out the ouput for arcue.exe (both versions)

Code: [Select]
Checking AccurateRip database

Track   Ripping Status          [Disc ID: 0043e4fe-7c128c1b]

1      Accurately Ripped    (confidence 200)     [adb68f0f]
2      Accurately Ripped    (confidence 200)     [58331972]
3      Accurately Ripped    (confidence 200)     [3bcd3e3b]
4      Accurately Ripped    (confidence 200)     [31b8eb99]
5      Accurately Ripped    (confidence 200)     [04ea6254]
6      Accurately Ripped    (confidence 200)     [3f523f33]
7      Accurately Ripped    (confidence 200)     [dba3a427]
8      Accurately Ripped    (confidence 200)     [a1d91192]
9      Accurately Ripped    (confidence 200)     [06a8e557]
10     Accurately Ripped    (confidence 200)     [b20b75b4]
11     Accurately Ripped    (confidence 200)     [5e8a1fe6]
12     Accurately Ripped    (confidence 200)     [7ec3b3f2]
13     Accurately Ripped    (confidence 200)     [f8067b7a]
14     Accurately Ripped    (confidence 200)     [eb8d5713]
15     Accurately Ripped    (confidence 200)     [677bde1a]
16     Accurately Ripped    (confidence 200)     [3545f265]
17     Accurately Ripped    (confidence 200)     [5498403d]
18     Accurately Ripped    (confidence 200)     [e1ad245d]
19     Accurately Ripped    (confidence 200)     [139d6a70]
20     Accurately Ripped    (confidence 200)     [13205fec]
21     Accurately Ripped    (confidence 200)     [3e2a5e47]
22     Accurately Ripped    (confidence 200)     [d4c48fd6]
23     Accurately Ripped    (confidence 200)     [59e081a6]
24     Accurately Ripped    (confidence 200)     [3dd1ab41]
25     Accurately Ripped    (confidence 200)     [1868316f]
26     Accurately Ripped    (confidence 200)     [6c35cfc5]
27     Accurately Ripped    (confidence 200)     [1f9a4378]

_______________________

All Tracks Accurately Ripped.


and the ouput from CUETools Update8, using both Verify methods.

Code: [Select]
[Disc ID: 0043e4fe-0542e71b-7c128c1b]
Track    [ CRC    ] Status
01    [00000000] Database access error PartialContent
02    [00000000] Database access error PartialContent
03    [00000000] Database access error PartialContent
04    [00000000] Database access error PartialContent
05    [00000000] Database access error PartialContent
06    [00000000] Database access error PartialContent
07    [00000000] Database access error PartialContent
08    [00000000] Database access error PartialContent
09    [00000000] Database access error PartialContent
10    [00000000] Database access error PartialContent
11    [00000000] Database access error PartialContent
12    [00000000] Database access error PartialContent
13    [00000000] Database access error PartialContent
14    [00000000] Database access error PartialContent
15    [00000000] Database access error PartialContent
16    [00000000] Database access error PartialContent
17    [00000000] Database access error PartialContent
18    [00000000] Database access error PartialContent
19    [00000000] Database access error PartialContent
20    [00000000] Database access error PartialContent
21    [00000000] Database access error PartialContent
22    [00000000] Database access error PartialContent
23    [00000000] Database access error PartialContent
24    [00000000] Database access error PartialContent
25    [00000000] Database access error PartialContent
26    [00000000] Database access error PartialContent
27    [00000000] Database access error PartialContent


N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2008-10-26 13:34:16
I'm only worrying that soon that options window will be so huge it won't fit on screen

If you are going to add these specialized changes that may rarely be used, maybe you should have them enabled in a config file to keep the options window clean!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2008-10-27 18:20:28
I had the same error as NachoMan77. In my case the CDs resulting in the "Database access error PartialContent" errors for every track were "Reba #1's" both CD 1 and 2. I thought that perhaps the '#' sign in the CD title might be causing a problem. ARCue says that all tracks for both CDs are all accurately ripped.

When I tried TripleFlac, I got the error "Error parsing the DB file, maybe it's corrupt..." in a pop-up window, but the text area says:

Contacting AccurateRip [LeadIn: 0] - http://www.accuraterip.com/accuraterip/F/3...70-080D7F11.bin (http://www.accuraterip.com/accuraterip/F/3/C/dBAR-017-00228C3F-01B86C70-080D7F11.bin)
HTTP respone: OK - read 1783 bytes from server, contains 10 set(s)

I hope this helps.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-11-09 13:13:58
This is really cool:

$ mono ArCueDotNet.exe /tmp/Electric\ Light\ Orchestra\ -\ Discovery.flac.cue
[Disc ID: 00162eed-00ca7a8c-a70a3c0c]
Track  [ CRC    ] Status
01    [590412c6] (24/37) Accurately ripped as in pressing(s) #1
02    [b6aaf1ce] (24/39) Accurately ripped as in pressing(s) #1
03    [2ab63e0b] (24/39) Accurately ripped as in pressing(s) #1
04    [ca7539bf] (24/39) Accurately ripped as in pressing(s) #1
05    [f5392440] (24/40) Accurately ripped as in pressing(s) #1
06    [ec015f5b] (24/39) Accurately ripped as in pressing(s) #1
07    [a6d3e102] (24/40) Accurately ripped as in pressing(s) #1
08    [e9066146] (24/39) Accurately ripped as in pressing(s) #1
09    [3327a526] (24/40) Accurately ripped as in pressing(s) #1
10    [0577d3f2] (24/39) Accurately ripped as in pressing(s) #1
11    [941751ca] (24/40) Accurately ripped as in pressing(s) #1
12    [e5ea5616] (21/36) Accurately ripped as in pressing(s) #1
Offsetted by -664:
01    [463a552e] (00/37) No matches
02    [a5069b4e] (02/39) Accurately ripped as in pressing(s) #4
03    [2b39088b] (02/39) Accurately ripped as in pressing(s) #4
04    [d10455c7] (02/39) Accurately ripped as in pressing(s) #4
05    [28ffb5e8] (02/40) Accurately ripped as in pressing(s) #4
06    [5d5512c3] (02/39) Accurately ripped as in pressing(s) #4
07    [b5bfdc2a] (02/40) Accurately ripped as in pressing(s) #4
08    [a84bc556] (02/39) Accurately ripped as in pressing(s) #4
09    [0dd67f7e] (02/40) Accurately ripped as in pressing(s) #4
10    [c58da01a] (02/39) Accurately ripped as in pressing(s) #4
11    [a31e2442] (02/40) Accurately ripped as in pressing(s) #4
12    [894c08fe] (02/36) Accurately ripped as in pressing(s) #4

I believe there's a mkbundle command for mono that will embed all the DLL into a single Linux executable which is probably a good idea, these JIT languages are the software version of Humpty Dumpty in my opinion.

Anyone have a clue on this one?:
$ mono CUETools.exe

** (CUETools.exe:30985): WARNING **: The following assembly referenced from /home/michael/smb/cueTools-192/CUETools.exe could not be loaded:
    Assembly:  System.Windows.Forms    (assemblyref_index=0)
    Version:    2.0.0.0
    Public Key: b77a5c561934e089
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/michael/smb/cueTools-192/).


** (CUETools.exe:30985): WARNING **: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
File name: 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
michael@corwin:~/smb/cueTools-192$
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-11-09 13:26:37
Just wanted to let people know that the "CUE Tools has encountered a problem and needs to close." messages can be caused by running it over a (in my case Samba) network share. Copy it to the C drive to run it and it will work.

** (CUETools.exe:30985): WARNING **: The following assembly referenced from /home/michael/smb/cueTools-192/CUETools.exe could not be loaded:

Can it be that it's a samba problem again?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-11-09 14:30:18

** (CUETools.exe:30985): WARNING **: The following assembly referenced from /home/michael/smb/cueTools-192/CUETools.exe could not be loaded:

Can it be that it's a samba problem again?


I can't accuse you of not being alert! No, that is a regular path, you are correct that the /home/michael/smb path is shared via samba for windows as z:, but I'm on the Linux side of things reading from a plain ext3 mount.

I figured out how to turn the .net CLI utility into a Linux excutable:

mkbundle2 ArCueDotNet.exe CUEToolsLib.dll FLACDotNet.dll WavPackDotNet.dll APEDotNet.dll -o ArCueTools

It works on wav files, and guaranteed to crash on Flac and Ape. I haven't tested Wavepack but I'd be shocked if it didn't crash too. In any case it's like an improved version of ARCue.pl
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-11-10 17:38:33
Does this make any sense?
Code: [Select]
Black Sabbath - Paranoid.flac: done
[Disc ID: 000d44e3-005781a4-6b09df08]
Track  [ CRC ] Status
 01 [4a3fc0dd] (00/118) No matches
 02 [a9382641] (00/118) No matches
 03 [ebf74add] (00/116) No matches
 04 [f3e09b5e] (00/117) No matches
 05 [388e462b] (00/119) No matches
 06 [b205e57f] (00/117) No matches
 07 [ec94db4d] (00/117) No matches
 08 [5592d775] (00/119) No matches
Offsetted by -2329:
 01 [8580c981] (14/118) Accurately ripped as in pressing(s) #3
 02 [b1ecbe18] (14/118) Accurately ripped as in pressing(s) #3
 03 [2272ffa6] (14/116) Accurately ripped as in pressing(s) #3
 04 [37a0223c] (14/117) Accurately ripped as in pressing(s) #3
 05 [d6ee91f1] (14/119) Accurately ripped as in pressing(s) #3
 06 [89f40115] (14/117) Accurately ripped as in pressing(s) #3
 07 [bdeba42a] (14/117) Accurately ripped as in pressing(s) #3
 08 [82fe2267] (00/119) No matches
Offsetted by -1757:
 01 [05e47e4d] (02/118) Accurately ripped as in pressing(s) #7
 02 [fac056ac] (02/118) Accurately ripped as in pressing(s) #7
 03 [1465de4e] (02/116) Accurately ripped as in pressing(s) #7
 04 [d51ce5bb] (02/117) Accurately ripped as in pressing(s) #7
 05 [c0777d9c] (02/119) Accurately ripped as in pressing(s) #7
 06 [6c90dafa] (02/117) Accurately ripped as in pressing(s) #7
 07 [9a8862fb] (02/117) Accurately ripped as in pressing(s) #7
 08 [b8b779c6] (00/119) No matches
Offsetted by -1665:
 01 [f579acad] (38/118) Accurately ripped as in pressing(s) #2
 02 [bbfa8a70] (37/118) Accurately ripped as in pressing(s) #2
 03 [060b706a] (36/116) Accurately ripped as in pressing(s) #2
 04 [2c3d5cf2] (36/117) Accurately ripped as in pressing(s) #2
 05 [d546b81d] (38/119) Accurately ripped as in pressing(s) #2
 06 [d69ab457] (36/117) Accurately ripped as in pressing(s) #2
 07 [983a88f2] (36/117) Accurately ripped as in pressing(s) #2
 08 [7788ae05] (00/119) No matches
Offsetted by -1010:
 01 [5ab5402a] (06/118) Accurately ripped as in pressing(s) #8
 02 [f80697e6] (06/118) Accurately ripped as in pressing(s) #8
 03 [89f871bd] (06/116) Accurately ripped as in pressing(s) #8
 04 [226b2799] (06/117) Accurately ripped as in pressing(s) #8
 05 [d8041e03] (06/119) Accurately ripped as in pressing(s) #8
 06 [64fee3c7] (06/117) Accurately ripped as in pressing(s) #8
 07 [45b7aa73] (06/117) Accurately ripped as in pressing(s) #8
 08 [9c76b54d] (00/119) No matches
Offsetted by -1008:
 01 [c8eb3075] (20/118) Accurately ripped as in pressing(s) #5
 02 [8cd80858] (21/118) Accurately ripped as in pressing(s) #5
 03 [9e2b9bda] (20/116) Accurately ripped as in pressing(s) #5
 04 [c4474076] (21/117) Accurately ripped as in pressing(s) #5
 05 [b5556d9b] (21/119) Accurately ripped as in pressing(s) #5
 06 [72191509] (21/117) Accurately ripped as in pressing(s) #5
 07 [069262e6] (21/117) Accurately ripped as in pressing(s) #5
 08 [cb790576] (00/119) No matches
Offsetted by -738:
 01 [fd79d20e] (08/118) Accurately ripped as in pressing(s) #1
 02 [a0b20dcc] (08/118) Accurately ripped as in pressing(s) #1
 03 [44bacfd7] (08/116) Accurately ripped as in pressing(s) #1
 04 [a5118088] (08/117) Accurately ripped as in pressing(s) #1
 05 [ca578bdb] (08/119) Accurately ripped as in pressing(s) #1
 06 [1526e2d9] (08/117) Accurately ripped as in pressing(s) #1
 07 [3ebffb8c] (08/117) Accurately ripped as in pressing(s) #1
 08 [4e464aa7] (00/119) No matches
Offsetted by -265:
 01 [b5d7e187] (05/118) Accurately ripped as in pressing(s) #4
 02 [29867165] (05/118) Accurately ripped as in pressing(s) #4
 03 [380c013d] (05/116) Accurately ripped as in pressing(s) #4
 04 [e79b9a92] (05/117) Accurately ripped as in pressing(s) #4
 05 [c687a648] (05/119) Accurately ripped as in pressing(s) #4
 06 [b67a397e] (05/117) Accurately ripped as in pressing(s) #4
 07 [5741e2f4] (05/117) Accurately ripped as in pressing(s) #4
 08 [f8c0d9b8] (05/119) Accurately ripped as in pressing(s) #4
for track 8, where are the missing 114 results?

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Please use codebox instead of code when posting logs, cues and other long items.[/size]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2008-11-10 17:49:41
Yes, that makes sense.

Where were the missing 114 results?  Your track didn't match them and considering you're talking about the last track, this is really not all that unusual.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-11-10 20:32:27
Does this make any sense?
Black Sabbath - Paranoid.flac: done
08    [f8c0d9b8] (05/119) Accurately ripped as in pressing(s) #4
for track 8, where are the missing 114 results?


Hard to tell. Most probably there really are two pressings of this disc (if we forget about the pressings which differ only in offset) - e.g. european and us versions, or limited edition of some kind, which have different mixes of the last track - maybe a beep over the f* word or something?  You happen to have authentic, but less popular pressing.

It is also possible, that your pressing is just the most complete - all non-matching pressings have higher negative offsets, which means more data was cut from the end of the disc, which doesn't end on digital silence.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-11-11 15:58:33
Thanks for the responses to my previous post. I have one more and then I'll try to be quiet. I see the same pattern quite a bit which does look like a bug to me:

Code: [Select]
[Disc ID: 00238fef-01cb0e55-eb0df911]
Track  [ CRC    ] Status
 01    [128ece05] (18/37) Accurately ripped as in pressing(s) #1
 02    [713a3a33] (18/37) Accurately ripped as in pressing(s) #2
 03    [c2fa4daa] (17/36) Accurately ripped as in pressing(s) #2
 04    [df0ba459] (17/36) Accurately ripped as in pressing(s) #2
 05    [702d4208] (18/38) Accurately ripped as in pressing(s) #2
 06    [90bee105] (18/38) Accurately ripped as in pressing(s) #2
 07    [7f53316a] (18/37) Accurately ripped as in pressing(s) #2
 08    [2147ec0b] (17/34) Accurately ripped as in pressing(s) #2
 09    [0c448431] (18/37) Accurately ripped as in pressing(s) #2
 10    [d5fe57da] (18/35) Accurately ripped as in pressing(s) #2
 11    [289a02ad] (18/38) Accurately ripped as in pressing(s) #2
 12    [bca78ec8] (18/35) Accurately ripped as in pressing(s) #2
 13    [353445ae] (18/38) Accurately ripped as in pressing(s) #2
 14    [6250941a] (18/35) Accurately ripped as in pressing(s) #2
 15    [902d41a9] (17/36) Accurately ripped as in pressing(s) #2
 16    [2ec47b5f] (17/37) Accurately ripped as in pressing(s) #2
 17    [acc578c5] (16/35) Accurately ripped as in pressing(s) #1
Offsetted by 1162:
 01    [341c1a9d] (06/37) Accurately ripped as in pressing(s) #3
 02    [1c55188b] (07/37) Accurately ripped as in pressing(s) #1
 03    [33eca4cc] (07/36) Accurately ripped as in pressing(s) #1
 04    [aa247909] (07/36) Accurately ripped as in pressing(s) #1
 05    [17a35430] (07/38) Accurately ripped as in pressing(s) #1
 06    [05fec5c9] (07/38) Accurately ripped as in pressing(s) #1
 07    [ecd2f9b0] (07/37) Accurately ripped as in pressing(s) #1
 08    [7179ec0b] (07/34) Accurately ripped as in pressing(s) #1
 09    [88acbb8b] (07/37) Accurately ripped as in pressing(s) #1
 10    [0809327c] (07/35) Accurately ripped as in pressing(s) #1
 11    [cf5ea50d] (07/38) Accurately ripped as in pressing(s) #1
 12    [e2d18ec8] (05/35) Accurately ripped as in pressing(s) #1
 13    [d42be102] (07/38) Accurately ripped as in pressing(s) #1
 14    [27a89634] (07/35) Accurately ripped as in pressing(s) #1
 15    [1113a8d7] (07/36) Accurately ripped as in pressing(s) #1
 16    [57102c61] (07/37) Accurately ripped as in pressing(s) #1
 17    [24e778c5] (06/35) Accurately ripped as in pressing(s) #3
Offsetted by 1463:
 01    [b82ca849] (13/37) Accurately ripped as in pressing(s) #2
 02    [a219be17] (12/37) Accurately ripped as in pressing(s) #3
 03    [9fd50ea5] (12/36) Accurately ripped as in pressing(s) #3
 04    [a110b021] (12/36) Accurately ripped as in pressing(s) #3
 05    [9c7658e4] (13/38) Accurately ripped as in pressing(s) #3
 06    [2d9ebebb] (13/38) Accurately ripped as in pressing(s) #3
 07    [ed6de82b] (12/37) Accurately ripped as in pressing(s) #3
 08    [ca1aec0b] (10/34) Accurately ripped as in pressing(s) #3
 09    [faa2b760] (12/37) Accurately ripped as in pressing(s) #3
 10    [b0c1fc15] (10/35) Accurately ripped as in pressing(s) #3
 11    [8b8853bd] (13/38) Accurately ripped as in pressing(s) #3
 12    [274e8ec8] (12/35) Accurately ripped as in pressing(s) #3
 13    [58566d7c] (13/38) Accurately ripped as in pressing(s) #3
 14    [8c208a69] (10/35) Accurately ripped as in pressing(s) #3
 15    [1214bd66] (12/36) Accurately ripped as in pressing(s) #3
 16    [72770eaa] (13/37) Accurately ripped as in pressing(s) #3
 17    [034078c5] (13/35) Accurately ripped as in pressing(s) #2
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2008-11-11 16:31:41
How would this one be explained? Seems like a rounding error to me.

Code: [Select]
[Disc ID: 0018697f-00f80b89-b00c430d]
Track  [ CRC    ] Status
 01    [7ba570e8] (02/130) Accurately ripped as in pressing(s) #5
 02    [6d4e58f0] (02/128) Accurately ripped as in pressing(s) #5
 03    [08762704] (02/128) Accurately ripped as in pressing(s) #5
 04    [0cb12b93] (02/127) Accurately ripped as in pressing(s) #5
 05    [bbfd421f] (02/128) Accurately ripped as in pressing(s) #5
 06    [7e6ec07f] (02/130) Accurately ripped as in pressing(s) #5
 07    [adcac188] (02/128) Accurately ripped as in pressing(s) #5
 08    [33d4c182] (02/128) Accurately ripped as in pressing(s) #5
 09    [44aebab2] (02/127) Accurately ripped as in pressing(s) #5
 10    [5082a7b1] (02/127) Accurately ripped as in pressing(s) #5
 11    [7ce382a0] (02/125) Accurately ripped as in pressing(s) #5
 12    [52eb8127] (02/125) Accurately ripped as in pressing(s) #5
 13    [44a4affe] (02/125) Accurately ripped as in pressing(s) #5
Offsetted by -1417:
 01    [17a89335] (06/130) Partial match to pressing(s) #6
 02    [3e183147] (06/128) Accurately ripped as in pressing(s) #6
 03    [be29b067] (06/128) Accurately ripped as in pressing(s) #6
 04    [ed8f784e] (06/127) Accurately ripped as in pressing(s) #6
 05    [512077db] (06/128) Accurately ripped as in pressing(s) #6
 06    [26865a5d] (06/130) Accurately ripped as in pressing(s) #6
 07    [e3503627] (06/128) Accurately ripped as in pressing(s) #6
 08    [819e67dc] (00/128) No matches
 09    [d80fd4a8] (00/127) No matches
 10    [ed4df26b] (00/127) No matches
 11    [a8cbda8e] (00/125) No matches
 12    [5d6bf3a1] (00/125) No matches
 13    [e607484b] (00/125) No matches
Offsetted by -1416:
 01    [494c7fe5] (00/130) No matches
 02    [d8125ea3] (00/128) No matches
 03    [919767dc] (00/128) No matches
 04    [3976052b] (00/127) No matches
 05    [de1ea2ff] (00/128) No matches
 06    [733028ef] (00/130) No matches
 07    [517aef40] (00/128) No matches
 08    [270d30d2] (06/128) Accurately ripped as in pressing(s) #6
 09    [3688a4b1] (06/127) Accurately ripped as in pressing(s) #6
 10    [000fc312] (06/127) Accurately ripped as in pressing(s) #6
 11    [19dc4f90] (06/125) Accurately ripped as in pressing(s) #6
 12    [af413977] (06/125) Accurately ripped as in pressing(s) #6
 13    [845b38a6] (06/125) Accurately ripped as in pressing(s) #6
Offsetted by -1051:
 01    [03a500ad] (02/130) Accurately ripped as in pressing(s) #4
 02    [7ec0c413] (02/128) Accurately ripped as in pressing(s) #4
 03    [0505f9ad] (02/128) Accurately ripped as in pressing(s) #4
 04    [712cdc44] (02/127) Accurately ripped as in pressing(s) #4
 05    [e4822553] (02/128) Accurately ripped as in pressing(s) #4
 06    [c14baf19] (02/130) Accurately ripped as in pressing(s) #4
 07    [6464d7e5] (02/128) Accurately ripped as in pressing(s) #4
 08    [0601b790] (00/128) No matches
 09    [5d45e596] (00/127) No matches
 10    [80800c55] (00/127) No matches
 11    [4e53236a] (00/125) No matches
 12    [5c55cb95] (00/125) No matches
 13    [4208ea65] (00/125) No matches
Offsetted by -1050:
 01    [5b18e662] (00/130) No matches
 02    [b96053c6] (00/128) No matches
 03    [d873b122] (00/128) No matches
 04    [bd136921] (00/127) No matches
 05    [71805077] (00/128) No matches
 06    [0df57dab] (00/130) No matches
 07    [d28f90fe] (00/128) No matches
 08    [ab708086] (02/128) Accurately ripped as in pressing(s) #4
 09    [bc2cb610] (02/127) Accurately ripped as in pressing(s) #4
 10    [92d3dc8b] (02/127) Accurately ripped as in pressing(s) #4
 11    [bf63986c] (02/125) Accurately ripped as in pressing(s) #4
 12    [ae2b116b] (02/125) Accurately ripped as in pressing(s) #4
 13    [e05cdac0] (02/125) Accurately ripped as in pressing(s) #4
Offsetted by -753:
 01    [fdcb93f9] (42/130) Partial match to pressing(s) #1
 02    [baa97bc7] (40/128) Accurately ripped as in pressing(s) #1
 03    [22bd87df] (41/128) Accurately ripped as in pressing(s) #1
 04    [cb8cd586] (41/127) Accurately ripped as in pressing(s) #1
 05    [04605d3b] (43/128) Accurately ripped as in pressing(s) #1
 06    [fef6250d] (44/130) Accurately ripped as in pressing(s) #1
 07    [a2204eff] (42/128) Accurately ripped as in pressing(s) #1
 08    [98f7a5ec] (00/128) No matches
 09    [472af8f7] (00/127) No matches
 10    [b808fb54] (00/127) No matches
 11    [eb7b57be] (00/125) No matches
 12    [9e9916b1] (00/125) No matches
 13    [8fbeb453] (00/125) No matches
Offsetted by -752:
 01    [f8c8b890] (00/130) No matches
 02    [907038c4] (00/128) No matches
 03    [f62b3f54] (00/128) No matches
 04    [17736263] (00/127) No matches
 05    [915e885f] (00/128) No matches
 06    [4b9ff39f] (00/130) No matches
 07    [104b0818] (00/128) No matches
 08    [3e666ee2] (41/128) Accurately ripped as in pressing(s) #1
 09    [a5b8c8f9] (41/127) Accurately ripped as in pressing(s) #1
 10    [ca2ccaba] (41/127) Accurately ripped as in pressing(s) #1
 11    [5c8bccc0] (40/125) Accurately ripped as in pressing(s) #1
 12    [f06e5c87] (41/125) Accurately ripped as in pressing(s) #1
 13    [2e12a4ae] (42/125) Accurately ripped as in pressing(s) #1
Offsetted by -475:
 01    [aa7b3f6e] (17/130) Accurately ripped as in pressing(s) #2
 02    [1c8d5b9e] (16/128) Accurately ripped as in pressing(s) #2
 03    [bbe2c0ed] (16/128) Accurately ripped as in pressing(s) #2
 04    [37e9cd84] (16/127) Accurately ripped as in pressing(s) #2
 05    [20633653] (16/128) Accurately ripped as in pressing(s) #2
 06    [3f5c7799] (16/130) Accurately ripped as in pressing(s) #2
 07    [44855025] (16/128) Accurately ripped as in pressing(s) #2
 08    [3f45e110] (16/128) Accurately ripped as in pressing(s) #2
 09    [fea8cb2a] (16/127) Accurately ripped as in pressing(s) #2
 10    [55b7ca99] (16/127) Accurately ripped as in pressing(s) #2
 11    [b35a67ea] (16/125) Accurately ripped as in pressing(s) #2
 12    [7c32ed15] (16/125) Accurately ripped as in pressing(s) #2
 13    [7ee5b725] (17/125) Accurately ripped as in pressing(s) #2
Offsetted by -390:
 01    [d4a59c7e] (61/130) Accurately ripped as in pressing(s) #3
 02    [223b106e] (62/128) Accurately ripped as in pressing(s) #3
 03    [ef50aac6] (61/128) Accurately ripped as in pressing(s) #3
 04    [6b7692e5] (60/127) Accurately ripped as in pressing(s) #3
 05    [f0c78947] (59/128) Accurately ripped as in pressing(s) #3
 06    [b3be0e13] (60/130) Accurately ripped as in pressing(s) #3
 07    [d8b4c572] (60/128) Accurately ripped as in pressing(s) #3
 08    [2d0e9abe] (00/128) No matches
 09    [9817822d] (00/127) No matches
 10    [49386e06] (00/127) No matches
 11    [3dd14194] (00/125) No matches
 12    [a8031d23] (00/125) No matches
 13    [10c4855c] (00/125) No matches
Offsetted by -389:
 01    [e5d269df] (00/130) No matches
 02    [c8a448d9] (00/128) No matches
 03    [c2be623b] (00/128) No matches
 04    [b75d1fc2] (00/127) No matches
 05    [7dc5b46b] (00/128) No matches
 06    [0067dca5] (00/130) No matches
 07    [46df7e8b] (00/128) No matches
 08    [d27d63b4] (61/128) Accurately ripped as in pressing(s) #3
 09    [f6245424] (60/127) Accurately ripped as in pressing(s) #3
 10    [5b1e3cbf] (60/127) Accurately ripped as in pressing(s) #3
 11    [aee1b696] (59/125) Accurately ripped as in pressing(s) #3
 12    [f9d862f9] (58/125) Accurately ripped as in pressing(s) #3
 13    [af1875b7] (56/125) Accurately ripped as in pressing(s) #3
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-11-11 18:21:12
Well, that's how they are in the database... not sure i can quite explain it, it's more of a question for mr Spoon  It seems to me that when the database is updated, a set of CRCs not necceceraly lands on one pressing. For each track AR database searches for a CRC match, if there is - just increases the count, if there isn't - creates a new pressing or puts it in the first pressing which has zero count for this disc.

So if the first person, who ripped this disc, only ripped the first and the last track, or the other way around - he failed to rip the first and the last track - and the next person had a different pressing, so they got tangled.

As for the second example, there can be no rounding error, because there's no rounding  Everything is computed in integers, nothing is divided. Probably this disc just has two versions, one has that extra sample between the 7th and the 8th track.

That's why for me the only reliable part of AR verification is ACCURATERIPCOUNTALLOFFSETS, i.e. sum of all the matches with all offsetted pressings. ACCURATERIPCOUNTALLOFFSETS should be very high for all tracks in both examples.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Quarck on 2008-11-12 02:34:58
I have decided to check up some rips by which did itself by Exact Audio Copy from firm disks. I converting my rips by foobar2000 into flac image with embedded cuesheet. Any has coincided on base accuraterip though broad gulls EAC suggest otherwise. After careful searches I have detected such thing. It appears at converting with parametre "convert to album images with cuesheets or chapters", foobar removes pregaps from cue of an image and the copy of the compressed image turns out not ideal. Somehow it is possible to solve this problem?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-11-12 23:26:05
I have decided to check up some rips by which did itself by Exact Audio Copy from firm disks. I converting my rips by foobar2000 into flac image with embedded cuesheet. Any has coincided on base accuraterip though broad gulls EAC suggest otherwise. After careful searches I have detected such thing. It appears at converting with parametre "convert to album images with cuesheets or chapters", foobar removes pregaps from cue of an image and the copy of the compressed image turns out not ideal. Somehow it is possible to solve this problem?

Did you keep the logs at least?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Quarck on 2008-11-13 02:12:50
Log created by Exact Audio Copy after ripping:
Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 13. November 2008, 9:01

Infinite Scale / Sound Sensor

Used drive  : ASUS    DRW-1814BL   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : No
Used interface                              : Installed external ASPI interface

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  6:51.04 |         0    |    30828  
        2  |  6:51.04 |  4:43.62 |     30829    |    52115  
        3  | 11:34.66 |  3:42.38 |     52116    |    68803  
        4  | 15:17.29 |  5:31.05 |     68804    |    93633  
        5  | 20:48.34 |  4:32.00 |     93634    |   114033  
        6  | 25:20.34 |  4:00.64 |    114034    |   132097  


Range status and errors

Selected range

     Filename E:\Infinite Scale - Sound Sensor.wav

     Peak level 99.4 %
     Range quality 99.9 %
     Copy CRC 0A86164B
     Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 7)  [CBC5D176]
Track  2  accurately ripped (confidence 7)  [B4CD2CEF]
Track  3  accurately ripped (confidence 7)  [CAD85BCE]
Track  4  accurately ripped (confidence 7)  [1C1CB6B9]
Track  5  accurately ripped (confidence 7)  [2A525140]
Track  6  accurately ripped (confidence 7)  [26CCA201]

All tracks accurately ripped

End of status report

Log created by Cue Tools after verifying ripped wav image:
Code: [Select]
[Disc ID: 00077ffb-0027382b-4406e106]
Track    [ CRC    ] Status
01    [cbc5d176] (07/07) Accurately ripped as in pressing(s) #1
02    [b4cd2cef] (07/07) Accurately ripped as in pressing(s) #1
03    [cad85bce] (07/07) Accurately ripped as in pressing(s) #1
04    [1c1cb6b9] (07/07) Accurately ripped as in pressing(s) #1
05    [2a525140] (07/07) Accurately ripped as in pressing(s) #1
06    [26cca201] (07/07) Accurately ripped as in pressing(s) #1

And Cue Tools log after verifying flac image converted by foobar2000 (flac 1.2.1):
Code: [Select]
[Disc ID: 00077ffb-0027382b-4406e106]
Track    [ CRC    ] Status
01    [aafd8969] (00/07) No matches
02    [79f51a60] (00/07) No matches
03    [871e02e3] (00/07) No matches
04    [6617fc8a] (00/07) No matches
05    [6cdfe457] (00/07) No matches
06    [cc1b094c] (00/07) No matches
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-11-13 05:41:29
Log created by Exact Audio Copy after ripping:

Very strange. Foobar usualy just looses the disc pregap, which leads to a different disc id, but the CRCs remain the same. Your logs show that the disc id is the same (there was no pregap in the original disc, so there was nothing to loose), but the CRCs are different. I don't understand what's going on. Broken flac encoder? Did you try to bit-compare the tracks? Please also check your converter settings in foobar, make sure that FLAC is configured right: prefered bit depth 16, keep lossless sources at original bit depth, and most importantly, dither: never.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Surfi on 2008-11-13 16:20:52
::

"Null samples used in CRC calculations" should be "Yes".

::
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2008-11-13 16:39:33
That doesn't affect AR checksums.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Quarck on 2008-11-13 17:04:59
My problem was because I enabled dithering in preferences of foobar2000, now it's ok. Thanks Gregory for solution.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2008-11-13 19:59:17
Thanks for this great program. Very handy. After testing this program for a while now, I have a feature request:

I would like a drag and drop system on the Cue sheet creator (or at least that it remembers the last used directory).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-11-18 15:15:22
Thanks for this great program. Very handy. After testing this program for a while now, I have a feature request:

I would like a drag and drop system on the Cue sheet creator (or at least that it remembers the last used directory).

Will probably look into it a bit later.

Please, check out the new version and feel free to add some documentation at project's Wiki page (http://wiki.hydrogenaudio.org/index.php?title=CueTools).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2008-11-19 12:41:42
Quote
I would like a drag and drop system on the Cue sheet creator (or at least that it remembers the last used directory).

Will probably look into it a bit later.


For me is it not necessary any more. This:


Quote
* input can be a directory with audio files and no cue sheet


has made the need for making a cue sheet in a quick way obsolete (at least for me) 

Thanks for all other improvements also!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-11-19 17:15:26
Gregory,

thanks a lot for the "encode if zero offset" option.

All your hard work in 1.9.3 is really apreciated. I'm gonna test it as soon as I get home.

nitpick: the truncate 4206 samples tooltip text is in russian.

Thanks,

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: naturfreak on 2008-11-20 00:21:39
Hmm... Looks like no one else find handling of audio CDs with pre emphased tracks useful.
I think it can be usefull because this info is lost when you spilt a CD image into seperate tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2008-11-25 12:19:27
Hi Gregory,

while testing enhanced data track rips I found the following minor issue.

With 1.9.3u1, if you specify a data track length it doesn't add the REM DATATRACKLENGTH tag to the cue file. I know that it uses the log file as default to get the data track length, and even if you had to input manually, the discID gets cached so further AR queries resolve correctly, BUT, I think that the DATATRACKLENGTH should be added anyway, for the following reasons:

1) correct me if i'm wrong, but CUETools can't pick up the data length from previous versions of EAC.

2) A user may change it's computer, thus loosing all the cached info. Then the rip won't verify unless the data track length is manually inputed. Please correct me on this, since I haven't spent much time figuring out how it works.

3) I believe that the CUE sheet is the logical place for all file related info to be. IMHO, if it's a disc attribute, it should live on the cue sheet.


Thanks for all the hard work !

N.

PS: please reconsider adding a file overwrite switch for batch jobs. It can even show a warning when the job starts, so that everybody knows its enabled.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2008-11-25 12:34:01
I use this tool since Moitah released it and I would like to thank Gregory for his great approvements.

At now one thing to mention: I use custom format %0\cdimage.cue as naming scheme. If nesessary (by double CDs) I change it to cdimage1.cue or cdimage2.cue.

In CUE Tools 1.9.1 I could also change the name of the resulting WAV file, in recent version its name remains always cdimage.wav.

I think it would be better to have the resulting file (in case of single file+cue) named equal to cue file.

Another question is CUE Sheet Creator: when I click the button and select the folder with audio files nothing happens.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2008-11-26 02:51:19
* fixed PartialContent error when reading huge AccurateRip entries


Gregory, thanks for fixing this problem in version 1.9.3.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-11-26 13:04:49
Hi Gregory,

while testing enhanced data track rips I found the following minor issue.

With 1.9.3u1, if you specify a data track length it doesn't add the REM DATATRACKLENGTH tag to the cue file. I know that it uses the log file as default to get the data track length, and even if you had to input manually, the discID gets cached so further AR queries resolve correctly, BUT, I think that the DATATRACKLENGTH should be added anyway, for the following reasons:

1) correct me if i'm wrong, but CUETools can't pick up the data length from previous versions of EAC.

2) A user may change it's computer, thus loosing all the cached info. Then the rip won't verify unless the data track length is manually inputed. Please correct me on this, since I haven't spent much time figuring out how it works.

3) I believe that the CUE sheet is the logical place for all file related info to be. IMHO, if it's a disc attribute, it should live on the cue sheet.


Thanks for all the hard work !

N.

PS: please reconsider adding a file overwrite switch for batch jobs. It can even show a warning when the job starts, so that everybody knows its enabled.


ACCURATERIPDISCID is stored in file tags AND in the cue sheet. There's no cache on your computer other than that. I doesn't make much sense to store both DATATRACKLENGTH and ACCURATERIPDISCID, because only one of them would be used.

I think i'll add two options for batch jobs, 'overwrite existing files' and a more safe 'skip on errors' option.

I use this tool since Moitah released it and I would like to thank Gregory for his great approvements.

At now one thing to mention: I use custom format %0\cdimage.cue as naming scheme. If nesessary (by double CDs) I change it to cdimage1.cue or cdimage2.cue.

In CUE Tools 1.9.1 I could also change the name of the resulting WAV file, in recent version its name remains always cdimage.wav.

I think it would be better to have the resulting file (in case of single file+cue) named equal to cue file.

Another question is CUE Sheet Creator: when I click the button and select the folder with audio files nothing happens.

Options, controling the name of the resulting WAV file are now in 'advanced options'.
You can turn off the 'keep original filenames' option, and set 'single format' to %F,
and your wav files will have the same name as a CUE sheet.

CUE Sheet Creator only works if you have a directory with file-per-track image and no CUE sheet.
It doesn't work if you already have a CUE sheet there, or if you have a single file image.
Can you show me a contents of the directory where it doesn't work?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2008-11-28 14:34:53
It doesn't work if you already have a CUE sheet there


Thanks, I think that was the reason.

The naming scheme works perfect, too. Spasibo 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marconelli on 2008-12-10 07:21:49
Thanks for this wonderful tool, Gregory, I use it very often

But I have a small (?) feature request. Would it be possible that the feature "input can be a directory with audio files and no cue sheet" also work in batch mode? I know that I can use the cuesheet creator, and it's ok when I check my files on hard drive... But when I want to check files previously written on dvd (and there's no cue sheet inside the directory) - that feature would be very usefull. For now it doesn't work in batch mode (or at least I don't know how to use it), when I select a directory in which there are audio files only, it says: "Exception: Input CUE Sheet not found"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: foorious on 2008-12-10 12:24:53
I too would appreciate a batch mode where you could simply input a root directory, then CUEtools would scan recursively all the subdirectories for (example) separate FLAC files without any cuesheets, and do all the AR verification and tag-writing on all the files in one single batch operation. Could this be possible ? Thanks. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: yury_usa on 2008-12-15 04:48:16
Hi everyone. I receive an "Index was outside the bounds of bound of the array" exception when I try to convert tracks to CD Image.


Cue Sheet
Code: [Select]
REM GENRE country
REM DISCID 1B0E6C14
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Ray Charles"
TITLE "Greatest Country and Western Hits"
FILE "01 - Your Cheating Heart.flac" WAVE
  TRACK 01 AUDIO
TITLE "Your Cheating Heart"
PERFORMER "Ray Charles"
INDEX 01 00:00:00
  TRACK 02 AUDIO
TITLE "Hey Good Lookin'"
PERFORMER "Ray Charles"
INDEX 00 03:32:70
FILE "02 - Hey Good Lookin'.flac" WAVE
INDEX 01 00:00:00
  TRACK 03 AUDIO
TITLE "Take These Chains From My Heart"
PERFORMER "Ray Charles"
INDEX 00 02:10:58
FILE "03 - Take These Chains From My Heart.flac" WAVE
INDEX 01 00:00:00
  TRACK 04 AUDIO
TITLE "Don't Tell Me Your Troubles"
PERFORMER "Ray Charles"
INDEX 00 02:54:60
FILE "04 - Don't Tell Me Your Troubles.flac" WAVE
INDEX 01 00:00:00
  TRACK 05 AUDIO
TITLE "I Can't Stop Loving You"
PERFORMER "Ray Charles"
INDEX 00 02:05:03
FILE "05 - I Can't Stop Loving You.flac" WAVE
INDEX 01 00:00:00
  TRACK 06 AUDIO
TITLE "Just A Little Lovin' (Will Go A Long Way)"
PERFORMER "Ray Charles"
INDEX 00 04:11:56
FILE "06 - Just A Little Lovin' (Will Go A Long Way).flac" WAVE
INDEX 01 00:00:00
  TRACK 07 AUDIO
TITLE "It Makes No Difference Now"
PERFORMER "Ray Charles"
INDEX 00 03:27:32
FILE "07 - It Makes No Difference Now.flac" WAVE
INDEX 01 00:00:00
  TRACK 08 AUDIO
TITLE "You Don't Know Me"
PERFORMER "Ray Charles"
INDEX 00 03:31:45
FILE "08 - You Don't Know Me.flac" WAVE
INDEX 01 00:00:00
  TRACK 09 AUDIO
TITLE "You Are My Sunshine"
PERFORMER "Ray Charles"
INDEX 00 03:13:51
FILE "09 - You Are My Sunshine.flac" WAVE
INDEX 01 00:00:00
  TRACK 10 AUDIO
TITLE "I'll Never Stand In Your Way"
PERFORMER "Ray Charles"
INDEX 00 02:57:73
FILE "10 - I'll Never Stand In Your Way.flac" WAVE
INDEX 01 00:00:00
  TRACK 11 AUDIO
TITLE "Someday (You'll Want Me To Want You)"
PERFORMER "Ray Charles"
INDEX 00 02:16:52
FILE "11 - Someday (You'll Want Me To Want You).flac" WAVE
INDEX 01 00:00:00
  TRACK 12 AUDIO
TITLE "I Love You So Much It Hurts"
PERFORMER "Ray Charles"
INDEX 00 02:37:70
FILE "12 - I Love You So Much It Hurts.flac" WAVE
INDEX 01 00:00:00
  TRACK 13 AUDIO
TITLE "Careless Love"
PERFORMER "Ray Charles"
INDEX 00 03:32:20
FILE "13 - Careless Love.flac" WAVE
INDEX 01 00:00:00
  TRACK 14 AUDIO
TITLE "Oh, Lonesome Me"
PERFORMER "Ray Charles"
INDEX 00 03:41:58
FILE "14 - Oh, Lonesome Me.flac" WAVE
INDEX 01 00:00:00
  TRACK 15 AUDIO
TITLE "Hang Your Head In Shame"
PERFORMER "Ray Charles"
INDEX 00 02:09:47
FILE "15 - Hang Your Head In Shame.flac" WAVE
INDEX 01 00:00:00
  TRACK 16 AUDIO
TITLE "Midnight"
PERFORMER "Ray Charles"
INDEX 00 03:14:05
FILE "16 - Midnight.flac" WAVE
INDEX 01 00:00:00
  TRACK 17 AUDIO
TITLE "No Letter Today"
PERFORMER "Ray Charles"
INDEX 00 03:14:42
FILE "17 - No Letter Today.flac" WAVE
INDEX 01 00:00:00
  TRACK 18 AUDIO
TITLE "Crying Time"
PERFORMER "Ray Charles"
INDEX 00 02:58:42
FILE "18 - Crying Time.flac" WAVE
INDEX 01 00:00:00
  TRACK 19 AUDIO
TITLE "Together Agian"
PERFORMER "Ray Charles"
INDEX 00 03:00:37
FILE "19 - Together Agian.flac" WAVE
INDEX 01 00:00:00
  TRACK 20 AUDIO
TITLE "Don't Let Her Know"
PERFORMER "Ray Charles"
INDEX 00 02:37:50
FILE "20 - Don't Let Her Know.flac" WAVE
INDEX 01 00:00:00

Log
Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 27. March 2008, 6:36

Ray Charles / Greatest Country and Western Hits

Used drive  : _NEC DVD+-RW ND-6650A  Adapter: 1  ID: 0

Read mode   : Secure
Utilize accurate stream : Yes
Defeat audio cache   : Yes
Make use of C2 pointers : No

Read offset correction   : 48
Overread into Lead-In and Lead-Out   : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations   : Yes
Used interface   : Installed external ASPI interface
Gap handling : Appended to previous track

Used output format   : User Defined Encoder
Selected bitrate : 256 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files\Exact Audio Copy\bin\flac.exe
Additional command line options : -V -8 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


TOC of the extracted CD

Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  |  0:00.00 |  3:37.48 | 0 | 16322 
2  |  3:37.48 |  2:14.67 | 16323 | 26439 
3  |  5:52.40 |  2:58.63 | 26440 | 39852 
4  |  8:51.28 |  2:08.60 | 39853 | 49512 
5  | 11:00.13 |  4:16.10 | 49513 | 68722 
6  | 15:16.23 |  3:31.15 | 68723 | 84562 
7  | 18:47.38 |  3:35.32 | 84563 |  100719 
8  | 22:22.70 |  3:17.33 | 100720 |  115527 
9  | 25:40.28 |  3:01.50 | 115528 |  129152 
  10  | 28:42.03 |  2:20.40 | 129153 |  139692 
  11  | 31:02.43 |  2:42.45 | 139693 |  151887 
  12  | 33:45.13 |  3:36.37 | 151888 |  168124 
  13  | 37:21.50 |  3:46.10 | 168125 |  185084 
  14  | 41:07.60 |  2:13.30 | 185085 |  195089 
  15  | 43:21.15 |  3:17.30 | 195090 |  209894 
  16  | 46:38.45 |  3:17.68 | 209895 |  224737 
  17  | 49:56.38 |  3:01.30 | 224738 |  238342 
  18  | 52:57.68 |  3:04.12 | 238343 |  252154 
  19  | 56:02.05 |  2:41.03 | 252155 |  264232 
  20  | 58:43.08 |  2:49.57 | 264233 |  276964 


Track  1

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\01 - Your Cheating Heart.wav

Pre-gap length  0:00:02.00

Peak level 56.7 %
Track quality 100.0 %
Test CRC 81A37049
Copy CRC 81A37049
Accurately ripped (confidence 1)  [5B76EC4C]
Copy OK

Track  2

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\02 - Hey Good Lookin'.wav

Pre-gap length  0:00:04.70

Peak level 76.4 %
Track quality 100.0 %
Test CRC 0AA6B233
Copy CRC 0AA6B233
Accurately ripped (confidence 1)  [88F2C028]
Copy OK

Track  3

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\03 - Take These Chains From My Heart.wav

Pre-gap length  0:00:04.12

Peak level 60.6 %
Track quality 100.0 %
Test CRC 12DACC1C
Copy CRC 12DACC1C
Accurately ripped (confidence 1)  [0DD654F0]
Copy OK

Track  4

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\04 - Don't Tell Me Your Troubles.wav

Pre-gap length  0:00:04.04

Peak level 84.3 %
Track quality 100.0 %
Test CRC D7AE57CA
Copy CRC D7AE57CA
Accurately ripped (confidence 1)  [EBD12955]
Copy OK

Track  5

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\05 - I Can't Stop Loving You.wav

Pre-gap length  0:00:03.76

Peak level 58.9 %
Track quality 100.0 %
Test CRC B3FAA16E
Copy CRC B3FAA16E
Accurately ripped (confidence 1)  [49C222D0]
Copy OK

Track  6

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\06 - Just A Little Lovin' (Will Go A Long Way).wav

Pre-gap length  0:00:04.38

Peak level 89.7 %
Track quality 99.9 %
Test CRC 7C83CCCD
Copy CRC 7C83CCCD
Accurately ripped (confidence 1)  [4A29BD3E]
Copy OK

Track  7

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\07 - It Makes No Difference Now.wav

Pre-gap length  0:00:03.77

Peak level 67.4 %
Track quality 100.0 %
Test CRC B2E95B00
Copy CRC B2E95B00
Accurately ripped (confidence 1)  [CACD2A28]
Copy OK

Track  8

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\08 - You Don't Know Me.wav

Pre-gap length  0:00:03.82

Peak level 54.4 %
Track quality 100.0 %
Test CRC ADDBED1C
Copy CRC ADDBED1C
Accurately ripped (confidence 1)  [E151B000]
Copy OK

Track  9

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\09 - You Are My Sunshine.wav

Pre-gap length  0:00:03.76

Peak level 92.4 %
Track quality 99.9 %
Test CRC 531CC218
Copy CRC 531CC218
Accurately ripped (confidence 1)  [AD773E65]
Copy OK

Track 10

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\10 - I'll Never Stand In Your Way.wav

Pre-gap length  0:00:03.69

Peak level 63.6 %
Track quality 100.0 %
Test CRC 8EA14C29
Copy CRC 8EA14C29
Accurately ripped (confidence 1)  [73D3F01E]
Copy OK

Track 11

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\11 - Someday (You'll Want Me To Want You).wav

Pre-gap length  0:00:03.84

Peak level 73.2 %
Track quality 100.0 %
Test CRC 21855819
Copy CRC 21855819
Accurately ripped (confidence 1)  [A3D78AF1]
Copy OK

Track 12

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\12 - I Love You So Much It Hurts.wav

Pre-gap length  0:00:04.66

Peak level 58.7 %
Track quality 99.9 %
Test CRC 654749B3
Copy CRC 654749B3
Accurately ripped (confidence 1)  [B0BD7F53]
Copy OK

Track 13

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\13 - Careless Love.wav

Pre-gap length  0:00:04.22

Peak level 65.5 %
Track quality 99.9 %
Test CRC 3E55865E
Copy CRC 3E55865E
Accurately ripped (confidence 1)  [83A796C7]
Copy OK

Track 14

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\14 - Oh, Lonesome Me.wav

Pre-gap length  0:00:04.36

Peak level 97.7 %
Track quality 100.0 %
Test CRC FCC362B3
Copy CRC FCC362B3
Accurately ripped (confidence 1)  [F0BB7F6B]
Copy OK

Track 15

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\15 - Hang Your Head In Shame.wav

Pre-gap length  0:00:03.77

Peak level 57.7 %
Track quality 100.0 %
Test CRC 616D0C9C
Copy CRC 616D0C9C
Accurately ripped (confidence 1)  [D4565799]
Copy OK

Track 16

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\16 - Midnight.wav

Pre-gap length  0:00:03.33

Peak level 71.5 %
Track quality 99.9 %
Test CRC 0A63CD1E
Copy CRC 0A63CD1E
Accurately ripped (confidence 1)  [D52FA3A2]
Copy OK

Track 17

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\17 - No Letter Today.wav

Pre-gap length  0:00:03.34

Peak level 74.8 %
Track quality 100.0 %
Test CRC 383B89A8
Copy CRC 383B89A8
Accurately ripped (confidence 1)  [0E63EA3F]
Copy OK

Track 18

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\18 - Crying Time.wav

Pre-gap length  0:00:02.84

Peak level 64.8 %
Track quality 100.0 %
Test CRC 29BE6CBA
Copy CRC 29BE6CBA
Accurately ripped (confidence 1)  [F2C20ABA]
Copy OK

Track 19

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\19 - Together Agian.wav

Pre-gap length  0:00:03.66

Peak level 78.6 %
Track quality 99.9 %
Test CRC AB617EA4
Copy CRC AB617EA4
Accurately ripped (confidence 1)  [6E837438]
Copy OK

Track 20

Filename C:\Ray Charles - Greatest Country and Western Hits (1988) [FLAC] {DCC, Hoffman}\20 - Don't Let Her Know.wav

Pre-gap length  0:00:03.37

Peak level 68.5 %
Track quality 100.0 %
Test CRC D2371685
Copy CRC D2371685
Accurately ripped (confidence 1)  [6EE7FBA8]
Copy OK


All tracks accurately ripped

No errors occurred

End of status report

What could be wrong? When it reaches "writing track20", an error pops-up:

(http://pic.ipicture.ru/uploads/081215/oxRQUV3qdb.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2008-12-26 01:52:39
Great; now I finally found a GUI to split CUE files under Vista (the Medieval thing doesn't work well here).

But:
Only a ru-RU language thing?

I could do the de-DE translation... if needed.
(And if I get to know which files are affected.)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2008-12-28 12:29:45
I've used Cuesplit for a while now and came across a, imho, weird thing.
I encountered several albums in which the log says that all tracks were accurately ripped, but cuesplit says that disk is not in database.
The latest find is Van Morrison - Too Long In Exile where the XLD-log says it's accurately ripped ( confidence 10 on most files), but when I try Cuesplit it says Disk not present in database.
I also tried tripleflac with the same result (cd not found)
I found more albums but didn't notate which ones.

Another thing that I encountered is with p.e. Van Morrison - No Guru, No Method, No Teacher.
The EAC-log says accurately ripped (mostly confidence 6 (track 10 confidence 4)), but Cuetools says:

Code: [Select]
[Disc ID: 00139ba0-009e5bc7-7f0bff0a]
Track    [ CRC    ] Status
01    [34274a0d] (00/01) No matches
02    [4a1178d2] (00/01) No matches
03    [ff5e4602] (00/01) No matches
04    [0efd6970] (00/01) No matches
05    [958eaa2c] (00/01) No matches
06    [09e2d517] (00/01) No matches
07    [023f270b] (00/01) No matches
08    [e52341c8] (00/01) No matches
09    [7506f2d6] (00/01) No matches
10    [c6b07ac3] (00/01) No matches
Offsetted by 466:
01    [12916dbf] (01/01) Accurately ripped as in pressing(s) #1
02    [e93fd83e] (01/01) Accurately ripped as in pressing(s) #1
03    [418976c2] (01/01) Accurately ripped as in pressing(s) #1
04    [d1122276] (01/01) Accurately ripped as in pressing(s) #1
05    [74410c46] (01/01) Accurately ripped as in pressing(s) #1
06    [6db689e5] (01/01) Accurately ripped as in pressing(s) #1
07    [08eb0829] (01/01) Accurately ripped as in pressing(s) #1
08    [ad7cbf10] (01/01) Accurately ripped as in pressing(s) #1
09    [eeaa33c0] (01/01) Accurately ripped as in pressing(s) #1
10    [17fc11b1] (01/01) Partial match to pressing(s) #1


So only one set available.
Is it possible cuetools doesn't find all submitted sets?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-12-28 19:35:32
I've used Cuesplit for a while now and came across a, imho, weird thing.
I encountered several albums in which the log says that all tracks were accurately ripped, but cuesplit says that disk is not in database.
...
Is it possible cuetools doesn't find all submitted sets?

CDs are identified by the track lengths. Pregap and data track included. If you rip to separate tracks without a .cue sheet, this information is lost. If the CD had a pregap and/or data track, you won't find it in the database without a .cue sheet (or using dimmy .cue sheet, or using foobar2k-generated .cue sheet). Sometimes you will find a wrong set, e.g. if the disc was released in two versions - with and without data track. You rip a version with data track, and verify it without a .cue sheet, and your files look like the version without a data track. Or you rip a CD which has a pregap, and try verify it without a .cue sheet, your files look like a CD-R which someone made from such a rip, and then ripped it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-12-28 19:58:37
Great; now I finally found a GUI to split CUE files under Vista (the Medieval thing doesn't work well here).

But:
Only a ru-RU language thing?

I could do the de-DE translation... if needed.
(And if I get to know which files are affected.)


Would be great. If you have MS Visual studio, than you just download the source code from SVN, open the solution (CUETools\CUETools.sln), look for CUETools project in solution browser, there doubleclick on frmCUETools.cs, select the appropriate 'Language' in the Properties window, and start editing the dialog by selecting the dialog elements one by one with a mouse, and changing 'Text' in the Properties window, and immediately see how it will look like. Then send me a frmCUETools.de-DE.resx file.

If you don't have MS Visual studio, you can still do this even with notepad, but that would be more painstalking process.
1) Download http://cuetoolsnet.svn.sourceforge.net/vie...rmCUETools.resx (http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/CUETools/frmCUETools.resx)
2) Open it with notepad (or OpenOffice or some other editor that understands UTF8 encoding).
3) For each <data name="*.Text"> and <data name="*.ToolTip"> section translate the text between <value> and </value>.
4) Send me the result.

If this doesn't kill you, you can also do the same with http://cuetoolsnet.svn.sourceforge.net/vie...rmSettings.resx (http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/CUETools/frmSettings.resx)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2008-12-28 20:52:29
If this doesn't kill you, you can also do the same with http://cuetoolsnet.svn.sourceforge.net/vie...rmSettings.resx (http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/CUETools/frmSettings.resx)

OK I tried; I hope I didn't break anything, lol.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2008-12-28 22:49:38
Quote
CDs are identified by the track lengths. Pregap and data track included. If you rip to separate tracks without a .cue sheet, this information is lost. If the CD had a pregap and/or data track, you won't find it in the database without a .cue sheet (or using dimmy .cue sheet, or using foobar2k-generated .cue sheet). Sometimes you will find a wrong set, e.g. if the disc was released in two versions - with and without data track. You rip a version with data track, and verify it without a .cue sheet, and your files look like the version without a data track. Or you rip a CD which has a pregap, and try verify it without a .cue sheet, your files look like a CD-R which someone made from such a rip, and then ripped it.


Thanks! That makes it clear, I thought I was going slightly mad 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2008-12-29 02:55:07
OK I tried; I hope I didn't break anything, lol.

Thanks. Hopefully i will include it in the next version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: frozenspeed on 2009-01-01 00:24:32
I keep getting the following error:

"Exception: Indexes must be in chronological order."

When I try to convert a wav/cuesheet I created from EAC. All the indexes look to be in order to me (I never touched the sheet), any idea what's going on? I've attached the cuesheet for this particular cd.

[attachment=4825:attachment]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Surfi on 2009-01-01 13:37:26
::

Look here:
  TRACK 10 AUDIO
   TITLE "Left Hand Shake (missing)"
   PERFORMER "Skinny Puppy"
   INDEX 00 41:56:42
   INDEX 01 41:56:45
  TRACK 11 AUDIO
   TITLE "Download"
   PERFORMER "Skinny Puppy"
   INDEX 00 41:56:41
   INDEX 01 41:56:50

Track 10 and 11 ... it's impossible! Try to change the Gap/Index retrieval method.

::
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: frozenspeed on 2009-01-01 16:46:43
::

Look here:
  TRACK 10 AUDIO
   TITLE "Left Hand Shake (missing)"
   PERFORMER "Skinny Puppy"
   INDEX 00 41:56:42
   INDEX 01 41:56:45
  TRACK 11 AUDIO
   TITLE "Download"
   PERFORMER "Skinny Puppy"
   INDEX 00 41:56:41
   INDEX 01 41:56:50

Track 10 and 11 ... it's impossible! Try to change the Gap/Index retrieval method.

::



Crazy!! That's a strange one, will do.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-01-01 17:46:54
With a track of only 5 frames, it's not surprising that detecting gaps would yield a problem.

If changing the method and/or accuracy doesn't help, just remove the 00 index from track 11.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zer on 2009-01-08 18:27:49
What would it take to make the flac plugin work under mono? I have attempted to familiarize myself with the issues, but I just do not have sufficient knowledge of .NET programming. I really want this to be fully functional on linux, and am inspired to help figure out how to make it happen, but am not sure where to start...

I have perused:
http://www.mono-project.com/Guide:_Porting...ms_Applications (http://www.mono-project.com/Guide:_Porting_Winforms_Applications)
but the anylizer claims that only UnRarDotNet.dll HDCDDotNet.dll are problematic, but I dont need those.

actually, I just tried a trial run, and the errors are about HDCD, not flac.
maybe just necessary to not load HDCD support if it is not needed? I only have 1 hdcd...

Think I got 1.9.1 to compile in  monodevelop a few weeks ago,
but it does not have the features I want, and the svn version has too much new stuff I cant figure out how to disable... cant find src for current ver.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-08 21:59:15
maybe just necessary to not load HDCD support if it is not needed? I only have 1 hdcd...

Flac support doesn't work on MONO, this has been tested on a version that didn't have hdcd or unrar support. The problem is, flac module is not a pure .NET module, it contains pure C libFLAC library, and MONO doesn't like these. So what we need is a C# libFLAC port.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-01-09 01:20:55
Gregory, would it be hard to squeeze in a EAC-compatible CRC (with use of null samples) check into the AR check process chain, so that the CUE Tools log would show the plus-null-sample CRCs for all found offsets? That would make it easy comparing the audio data to an old EAC log that only has the CRC and no AR results possible instead of running a check on that old rip's audio.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-09 07:07:22
Gregory, would it be hard to squeeze in a EAC-compatible CRC (with use of null samples) check into the AR check process chain, so that the CUE Tools log would show the plus-null-sample CRCs for all found offsets? That would make it easy comparing the audio data to an old EAC log that only has the CRC and no AR results possible instead of running a check on that old rip's audio.

I'll try. If somebody knows which algorithm is used for EAC CRCs, that would help a lot.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-01-09 09:21:17
Standard CRC32, but for the PCM data only.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-09 12:53:17
Standard CRC32, but for the PCM data only.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-01-09 18:06:15
If you're looking for an example implementation, there's an open source tool around... wavcrc32

http://www.hydrogenaudio.org/forums/index....st&p=514929 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=57306&view=findpost&p=514929)

It should also be useful when testing and debugging the CRC32 check in CUE Tools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bugs.Bunny on 2009-01-11 12:11:30
I do like Cue Tools a lot and I've got a small feature request:
I was wondering if it would be possible to add a CD-Text Corrector to the program - something similar to the Filename Corrector, that does correct the entries for CD TITLE, CD PERFORMER, Track TITLE and Track PERFORMER.
The FreeDB data can be used to fill this info in EAC and there can be errors / typos in that.
I do correct these errors and have the correct information in my APE tags and also in file and folder names.

Would it be possible to add a function that uses the Tags to correct (or fill if missing) these entries in the cue sheet?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-01-11 15:39:51
You can use Mp3Tag for editing the metadata in cue sheets, although it only supports the standard specifiaction, i.e. it's not possible to add 'REM <TAG FIELD> "<TAG DATA>" to a cue sheet with Mp3Tag. Meaning "REM DATE xxxx" is not supported by Mp3Tag, for example.

But it's one thing I like about Mp3Tag actually, because it helps me to clean up cue sheets quickly, for example if they were "redesigned" by foobar2000. All the extra metadata should be stored in tags anyway. Always remember what cue sheets where originally intended for, CD copying. But you wanted it for CD-Text only anyway, so Mp3Tag should be fine for now.

It would a be nice addition to CUE tools since it has a batch processor already, but the more features CUE Tools gets the more problematic will be fitting them all into the current UI, especially with something as UI-space-demanding as cue sheet metadata editing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mikesas on 2009-01-16 18:55:47
I am trying to split a single album FLAC image to multiple FLAC tracks.  The audio appears to split fine, but the individual files are only tagged with the Artist, Track Title, and Track #.  The Album Title tag is missing even though it is included in the the .cue.  I have tried this with multiple images with the same result so I am assuming that I must have something set up incorrectly.  Any suggestions or help?

Running the latest x64 version on Vista.  An example of one of my .cue files attached.

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-16 19:58:40
I am trying to split a single album FLAC image to multiple FLAC tracks.  The audio appears to split fine, but the individual files are only tagged with the Artist, Track Title, and Track #.  The Album Title tag is missing even though it is included in the the .cue.  I have tried this with multiple images with the same result so I am assuming that I must have something set up incorrectly.  Any suggestions or help?

Running the latest x64 version on Vista.  An example of one of my .cue files attached.

Thanks.

I confirm this is a bug, will be fixed in future version. Thanks.

Would it be possible to add a function that uses the Tags to correct (or fill if missing) these entries in the cue sheet?

CUETools has an option to fill missing cue-sheet entries from tags. As far as i remember, it's enabled by default. Limited freedb support is most likely to appear in future versions.
But i'm not really willing to create a powerfull tag editing UI.


Gregory, would it be hard to squeeze in a EAC-compatible CRC (with use of null samples) check into the AR check process chain, so that the CUE Tools log would show the plus-null-sample CRCs for all found offsets? That would make it easy comparing the audio data to an old EAC log that only has the CRC and no AR results possible instead of running a check on that old rip's audio.


Unfortunately CRC32 is a decent CRC, so it is not linear, and i cannot use the trick that i used to simultaneously calculate ArCRC for all offsets. I can easily calculate CRC32 for zero, or any other given offset, but i cannot know in advance for which exactly offsets should i do it. Offsets are found only after all the cd image has been processed, and i'd have to process it again to calculate CRC32 for the offsets that were found.

So i'm afraid i'll have to calculate CRC32 for zero offset only.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mikesas on 2009-01-16 20:06:43

I am trying to split a single album FLAC image to multiple FLAC tracks.  The audio appears to split fine, but the individual files are only tagged with the Artist, Track Title, and Track #.  The Album Title tag is missing even though it is included in the the .cue.  I have tried this with multiple images with the same result so I am assuming that I must have something set up incorrectly.  Any suggestions or help?

Running the latest x64 version on Vista.  An example of one of my .cue files attached.

Thanks.

I confirm this is a bug, will be fixed in future version. Thanks.

Thanks.  You probably know this already, but I also found one where I got no Artist Tag.  In this case the .cue did not have PERFORMER for each track.  It was only at the top for the Album.  If the .cue does not specify a PERFORMER on each track would you take the PERFORMER at the top and use it to set the Artist tag for each Track?  I hope that makes sense.

Is it also possible to auto correct for the file names in .cue that is in a RAR?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bugs.Bunny on 2009-01-16 22:22:47
Quote
CUETools has an option to fill missing cue-sheet entries from tags. As far as i remember, it's enabled by default. Limited freedb support is most likely to appear in future versions.
But i'm not really willing to create a powerfull tag editing UI.

I did a quick test and manually deleted out all PERFORMER and TITLE entries of a cue sheet and then did an encode. The new generated cue sheet had all the correct entries from the tags!
But to correct the entries this way is rather not so user friendly - I've a few hundred cue sheets. To manually delete out these entries on all of them and then encode is not something I'd like to do.
Maybe it's possible to integrate a drop box that performs the "fill missing cue-sheet entries from tags" function but not only fill - but rather overwrite cue-sheet entries from tags. That would be perfect.
I don't need a tag editing UI in cue tools nor do I need freedb support. Freedb has a lot of typos - I actually create the tags via dbpoweramp's perfect meta - so my tags are "more correct" than the entries from EAC + freedb that I use to create the cue sheets.
I think I'm not the only one using dbpoweramp (rip+tags) + eac (gaps+cue) so this would probably useful for more people.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-17 04:04:02
Is it also possible to auto correct for the file names in .cue that is in a RAR?


Maybe it's possible to integrate a drop box that performs the "fill missing cue-sheet entries from tags" function but not only fill - but rather overwrite cue-sheet entries from tags. That would be perfect.


Please, check out the new experimental version (1.9.4) in the first post of this thread.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-01-17 04:12:27
Aw I see my translations are somehow.. too long in some fields...
(And incomplete.)

 

Any chance to get write access on your SVN (maybe a special /lang folder)?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-17 04:18:53
Any chance to get write access on your SVN (maybe a special /lang folder)?

Sure. Just e-mail me your sourceforge account name.

And to everyone affected by gas shortages in EU, please consider this CUETools release as my apology for my goverment's idiocy
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-01-17 04:21:43
At least I'm not from Georgia.

You got some PM...

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zer on 2009-01-20 00:27:06
I have certainly found the "CUE Sheet Creator" a useful convenience, since I have plenty of rips from before I considered the possibility of "verifyably accuracy" (could care less about reburning cds...)

Unfortunately, such cuesheets are frequently useless because of a non-2second pregap.
since you now use freedb and Musicbrainz for metadata, why not use them to help create the proper cuesheeet/ArID? This would help in any case where the actual flacs are intact (or at least have the right length).

In fact, it could even help make a meaningful check against Ar when some files are truncated, or even missing.
I would like to know how accurate are even my bad rips. In one case, I have a disc where the last track wont rip, but its a bonus track I happen to not care about (it really doesnt belong on the album). It should not be required to make a bogus file of the correct length to check this album...

Sorry if I am taking this too far, but knowing the correct tracklengths should make it possible to check those unfortunate rips where some silence has been trimmed between tracks, by establishing bounds for how much it  must be offset shifted to check. Possibly the existing offset-detection could be used on a per-track basis if the length is wrong (within reason), just padded by silence?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-20 01:21:04
I have certainly found the "CUE Sheet Creator" a useful convenience, since I have plenty of rips from before I considered the possibility of "verifyably accuracy" (could care less about reburning cds...)

Unfortunately, such cuesheets are frequently useless because of a non-2second pregap.
since you now use freedb and Musicbrainz for metadata, why not use them to help create the proper cuesheeet/ArID? This would help in any case where the actual flacs are intact (or at least have the right length).

In fact, it could even help make a meaningful check against Ar when some files are truncated, or even missing.
I would like to know how accurate are even my bad rips. In one case, I have a disc where the last track wont rip, but its a bonus track I happen to not care about (it really doesnt belong on the album). It should not be required to make a bogus file of the correct length to check this album...

Sorry if I am taking this too far, but knowing the correct tracklengths should make it possible to check those unfortunate rips where some silence has been trimmed between tracks, by establishing bounds for how much it  must be offset shifted to check. Possibly the existing offset-detection could be used on a per-track basis if the length is wrong (within reason), just padded by silence?


It makes sense, but it's not all that easy.

I thought about using freedb to calculate Ar ids, but unfortunately freedb id is also based on track lengths, although they are less sensible - seconds instead of frames. So if your files have very slightly different length, there's a chance you will find a freedb entry and it will help you find Ar entry. Most of CDs with pregap, for example, have a pregap of 32 or 33 frames. Frame is 1/75th of a second, so there's less than 50% chance that a presense of pregap will change the offset of given track in seconds. For CD with two tracks, that means that your chance to find it in freedb despite lost pregap is less than 25%. It's about zero for a CD with 10 tracks.

Musicbrains has a way to look up cd entry using the audio itself as a key (audio fingerprinting), but it's a not very mature technology and too few CDs have been fingerprinted so far - i guess mainly because the fingerprinting software itself is proprietary.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zer on 2009-01-20 04:57:12
Possibly I misunderstand how you are using freedb/musicbrainz to fill in tags. I figgured you meant using a combination of searching for whatever existing tags, and comparing the disc structure. however, even if you only use them if they are stored in tags, I would still find this idea useful, for example I have some rips from dbpoweramp, that are tagged with cddb id and musicbrainz,  I would like to recheck accuraterip in some eventual bulk scan, but do not have any cuesheet. I have one or both of those discids stored in various ways for various ripping schemes and experiments. I just want the bulk verification to work in more cases, since I really had no interest in cuefiles for split albums until this 'verification' idea...

I thought about using freedb to calculate Ar ids, but unfortunately freedb id is also based on track lengths, although they are less sensible - seconds instead of frames. So if your files have very slightly different length, there's a chance you will find a freedb entry and it will help you find Ar entry. Most of CDs with pregap, for example, have a pregap of 32 or 33 frames. Frame is 1/75th of a second, so there's less than 50% chance that a presense of pregap will change the offset of given track in seconds. For CD with two tracks, that means that your chance to find it in freedb despite lost pregap is less than 25%. It's about zero for a CD with 10 tracks.


Ok, freedb ids are calculated by rounded seconds, but the returned xmcd files contain a list of frame-accurate offsets, including (importantly for this purpose) the lead in frame. what it does not include is the lead-out frame, that is why it is not sufficient to calculate ArID. Musicbrainz' ids include the lead-out frame though, and I believe have sufficient information to calculate the ArID...
http://musicbrainz.org/doc/DiscIDCalculation (http://musicbrainz.org/doc/DiscIDCalculation)
random example on freedb and musicbrainz
http://www.freedb.org/freedb/misc/7b0eee09 (http://www.freedb.org/freedb/misc/7b0eee09)
http://musicbrainz.org/show/cdtoc/?cdtocid=121699 (http://musicbrainz.org/show/cdtoc/?cdtocid=121699)
so, you can see that this one has a pregap of 32 frames, which is all we need to know to create the right cue sheet (if our files are intact, and the disc itself matched that particular freedb entry, of course)
just noticed I have cds w/ pre-emphasis while grepping cuefiles for pre-gaps, now I must determine what to do w/ those...

Quote
Musicbrains has a way to look up cd entry using the audio itself as a key (audio fingerprinting), but it's a not very mature technology and too few CDs have been fingerprinted so far - i guess mainly because the fingerprinting software itself is proprietary.

Quite a lot are fingerprinted, and it does appear to be the "most open" of fingerprinting efforts though, and if I am not mistaken there is an open implementation of the genpuid... I think the main problem with it is the somewhat cumbersome combination of picard tagger, and web forms that are required to effectively contribute to it... anyway, that is an interesting possibility also, but much more difficult, because a fingerprinted track could appear on many different releases, many of which would have differing ArCRCs, due to different offsets and gaps, at least...

generating a cuesheet that is much more likely to be right than assuming the standard pregap using the offsets from freedb or musicbrainz is not so complicated.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: caligae on 2009-01-31 18:13:52
I recently acquired my first HDCD. CUETools detects it as HDCD but the 24bit output file is the same as the original file, just quieter. In audacity, if I normalize, invert and mix the tracks together I just get silence.

I've selected "Decode HDCD to 20 bit" and store as 24 bit "lossless" and encoded it to flac.

In the result window I see:
HDCD: peak extend: none, transient filter: some, gain: none

Am I doing something wrong?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-01-31 19:45:18
HDCD: peak extend: none, transient filter: some, gain: none

There are three features in HDCD format: gain ajustment, peak extend and transient filter.
gain ajustment is the most common one.
peak extend is somewhat more rare, because it slightly distorts the sound when played on non-HDCD capable player.
transient filter is the most obscure, and not supported by software decoders.
Your CD is pretty wierd, it only uses the last (unsupported) feature.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: caligae on 2009-02-01 00:19:58
HDCD: peak extend: none, transient filter: some, gain: none

There are three features in HDCD format: gain ajustment, peak extend and transient filter.
gain ajustment is the most common one.
peak extend is somewhat more rare, because it slightly distorts the sound when played on non-HDCD capable player.
transient filter is the most obscure, and not supported by software decoders.
Your CD is pretty wierd, it only uses the last (unsupported) feature.


Thanks for the clarification. I didn't expect any great difference but wanted to try it. But it probably sounds much better on a hardware player thanks to placebo when the HDCD light is on
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-02-03 21:04:39
Just wondering why EAC's Accurate Rip claims that the CD is not in the database when CUEtools can find the same CD and detect it as accurate (when using the same EAC ripped disc image file).
 
I ripped the CD three times with EAC and did the Accurate Rip check with CUEtools twice. All EAC rips were bit to bit identical. Only CUEtools could find the CD from the Accuraterip DB.

The EAC log
Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 3. February 2009, 21:44

Kerkko Koskinen / Lolita

Used drive  : TSSTcorpCDDVDW SH-S202J  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : No
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  3:48.70 |        0    |    17169 
        2  |  3:48.70 |  3:06.38 |    17170    |    31157 
        3  |  6:55.33 |  3:20.37 |    31158    |    46194 
        4  | 10:15.70 |  2:55.06 |    46195    |    59325 
        5  | 13:11.01 |  3:07.40 |    59326    |    73390 
        6  | 16:18.41 |  3:15.04 |    73391    |    88019 
        7  | 19:33.45 |  3:26.41 |    88020    |  103510 
        8  | 23:00.11 |  3:11.67 |    103511    |  117902 
        9  | 26:12.03 |  4:07.04 |    117903    |  136431 
      10  | 30:19.07 |  3:13.37 |    136432    |  150943 
      11  | 33:32.44 |  2:51.15 |    150944    |  163783 
      12  | 36:23.59 |  3:58.59 |    163784    |  181692 


Range status and errors

Selected range

    Filename D:\Rip\Kerkko Koskinen - Lolita.wav

    Peak level 99.4 %
    Range quality 100.0 %
    Copy CRC 8697AA42
    Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  not present in database
Track  2  not present in database
Track  3  not present in database
Track  4  not present in database
Track  5  not present in database
Track  6  not present in database
Track  7  not present in database
Track  8  not present in database
Track  9  not present in database
Track 10  not present in database
Track 11  not present in database
Track 12  not present in database
 
None of the tracks are present in the AccurateRip database

End of status report

The cue sheet
Code: [Select]
REM GENRE Pop
REM DATE 2005
REM DISCID 9509760C
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Kerkko Koskinen"
TITLE "Lolita"
FILE "Kerkko Koskinen - Lolita.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Apilapelto"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500106
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Tätä miestä ei ruoste raiskaa"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500088
    INDEX 01 03:48:70
  TRACK 03 AUDIO
    TITLE "Sata rakastavaista"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500107
    INDEX 00 06:53:09
    INDEX 01 06:55:33
  TRACK 04 AUDIO
    TITLE "Elokuun pimeää"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500108
    INDEX 00 10:13:66
    INDEX 01 10:15:70
  TRACK 05 AUDIO
    TITLE "Suopursu"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500109
    INDEX 00 13:09:18
    INDEX 01 13:11:01
  TRACK 06 AUDIO
    TITLE "Lolita"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500110
    INDEX 01 16:18:41
  TRACK 07 AUDIO
    TITLE "Airot levossa"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500111
    INDEX 00 19:31:24
    INDEX 01 19:33:45
  TRACK 08 AUDIO
    TITLE "Olen heittänyt verkon"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500112
    INDEX 00 22:58:23
    INDEX 01 23:00:11
  TRACK 09 AUDIO
    TITLE "Kitara"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500113
    INDEX 00 26:09:29
    INDEX 01 26:12:03
  TRACK 10 AUDIO
    TITLE "Ei taida riittää"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500114
    INDEX 00 30:16:28
    INDEX 01 30:19:07
  TRACK 11 AUDIO
    TITLE "Kukurukukukuu"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500089
    INDEX 00 33:30:22
    INDEX 01 33:32:44
  TRACK 12 AUDIO
    TITLE "Kaislikossa suhisee"
    PERFORMER "Kerkko Koskinen"
    ISRC >f2K;0500115
    INDEX 00 36:20:72
    INDEX 01 36:23:59

The CUEtools/AR log:
Code: [Select]
[Verification date: 2009-02-03 21:57:30]
[Disc ID: 0011d877-00a66da7-9509760c]
Track [ CRC    ] Status
 01 [3b4d463f] (06/06) Accurately ripped as in pressing(s) #1
 02 [dbf2168a] (06/06) Accurately ripped as in pressing(s) #1
 03 [8c92c9b7] (06/06) Accurately ripped as in pressing(s) #1
 04 [dd69f8c3] (06/06) Accurately ripped as in pressing(s) #1
 05 [106735dd] (06/06) Accurately ripped as in pressing(s) #1
 06 [7f2ddd53] (06/06) Accurately ripped as in pressing(s) #1
 07 [698782ec] (06/06) Accurately ripped as in pressing(s) #1
 08 [4cc36980] (06/06) Accurately ripped as in pressing(s) #1
 09 [ca0e347d] (06/06) Accurately ripped as in pressing(s) #1
 10 [eac40e26] (06/06) Accurately ripped as in pressing(s) #1
 11 [b9717b01] (06/06) Accurately ripped as in pressing(s) #1
 12 [c4ca5fed] (06/06) Accurately ripped as in pressing(s) #1

Track [ CRC32  ]
 -- [3E0FE8DB]
 01 [824DC7B4]
 02 [00949257]
 03 [2746E5B5]
 04 [7089C2D6]
 05 [B9D54A6A]
 06 [DF68E14E]
 07 [D1FB0AFD]
 08 [8510A1E5]
 09 [CF820C25]
 10 [19D966CF]
 11 [64D43861]
 12 [44E515E3]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-02-03 21:10:20
Perhaps a bug in EAC.  Have you tried it with V0.95 and verified that the disc ID is the same as the one given by CUE Tools?

My recommendation is to send this along to Andre.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-02-03 21:46:53
Thanks, greynol.

Possibly it was some kind of temporary glitch with the accurate rip cache files. I cleared the cache files (I didn't post the suspicious results to the DB), restarted the PC and now I can't reproduce the problem.

EAC finds the CD from AR, verifies the tracks correctly and the results are identical with CUETools' results. Certainly it is not a problem with CUETools. If the problem comes back I'll report at the EAC forum.

Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 3. February 2009, 23:25

Kerkko Koskinen / Lolita

Used drive  : TSSTcorpCDDVDW SH-S202J  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : No
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  3:48.70 |        0    |    17169 
        2  |  3:48.70 |  3:06.38 |    17170    |    31157 
        3  |  6:55.33 |  3:20.37 |    31158    |    46194 
        4  | 10:15.70 |  2:55.06 |    46195    |    59325 
        5  | 13:11.01 |  3:07.40 |    59326    |    73390 
        6  | 16:18.41 |  3:15.04 |    73391    |    88019 
        7  | 19:33.45 |  3:26.41 |    88020    |  103510 
        8  | 23:00.11 |  3:11.67 |    103511    |  117902 
        9  | 26:12.03 |  4:07.04 |    117903    |  136431 
      10  | 30:19.07 |  3:13.37 |    136432    |  150943 
      11  | 33:32.44 |  2:51.15 |    150944    |  163783 
      12  | 36:23.59 |  3:58.59 |    163784    |  181692 


Range status and errors

Selected range

    Filename R:\Temp\Kerkko Koskinen - Lolita.wav

    Peak level 99.4 %
    Range quality 100.0 %
    Copy CRC 8697AA42
    Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 6)  [3B4D463F]
Track  2  accurately ripped (confidence 6)  [DBF2168A]
Track  3  accurately ripped (confidence 6)  [8C92C9B7]
Track  4  accurately ripped (confidence 6)  [DD69F8C3]
Track  5  accurately ripped (confidence 6)  [106735DD]
Track  6  accurately ripped (confidence 6)  [7F2DDD53]
Track  7  accurately ripped (confidence 6)  [698782EC]
Track  8  accurately ripped (confidence 6)  [4CC36980]
Track  9  accurately ripped (confidence 6)  [CA0E347D]
Track 10  accurately ripped (confidence 6)  [EAC40E26]
Track 11  accurately ripped (confidence 6)  [B9717B01]
Track 12  accurately ripped (confidence 6)  [C4CA5FED]
 
All tracks accurately ripped

End of status report
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-02-05 17:26:10
Hey Gregory! Isn't it about time to release "CUE Tools 2.0"?

You've added so many new features already, that it's long overdue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ggking7 on 2009-02-09 17:05:04
When I try to verify with AR, I get:

Error: Argument is out of range.
Parameter name: index

Does anyone know what this means?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2009-02-09 17:37:48
Error: Argument is out of range.
Parameter name: index


It's a runtime exception.

You can tell us your settings that caused this, like the offset value you used. You could also upload your .cue file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ggking7 on 2009-02-09 18:45:51
Error: Argument is out of range.
Parameter name: index


It's a runtime exception.

You can tell us your settings that caused this, like the offset value you used. You could also upload your .cue file.


I think that was a bad .cue file.  I've got a good one now but I'm getting a crash and Stacktrace.  I'm doing this in Linux, but it looks like another guy in this thread has it working fine.  Any ideas?

$ mono ArCueDotNet.exe file.cue
Stacktrace:
  at CUETools.Processor.AudioReadWrite.GetAudioSource (string,System.IO.Stream,string) <0xffffffff>
  at CUETools.Processor.AudioReadWrite.GetAudioSource (string,System.IO.Stream,string) <0x001cc>
  at CUETools.Processor.AudioReadWrite.GetAudioSource (string,System.IO.Stream) <0x000cc>
  at CUETools.Processor.CUESheet.GetSampleLength (string,System.Collections.Specialized.NameValueCollection&) <0x0008b>
  at CUETools.Processor.CUESheet.Open (string) <0x01b38>
  at ArCueDotNet.Program.Main (string[]) <0x00100>
  at (wrapper runtime-invoke) ArCueDotNet.Program.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
   mono [0x514d43]
   mono [0x4e3e3c]
   /lib/libpthread.so.0 [0x725dc74d0ec0]
   /lib/libc.so.6(memcpy+0x35) [0x725dc6f78905]
   mono(mono_class_vtable+0x438) [0x4b8ac1]
   mono(mono_runtime_class_init+0x112) [0x4b9e41]
   mono [0x50309c]
   mono [0x43dfec]
   [0x4098c139]
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Aborted
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-12 18:14:22
Hey Gregory! Isn't it about time to release "CUE Tools 2.0"?

Makes sense. But i'd like to hear Moitah's opinion on this first.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-12 18:28:58
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Aborted

I don't have a linux host to test CUETools with MONO currently.
There have been reports that CUETools modules that contain native code always crash under linux, and this includes FLAC support.
So far there have been reports of successful operation only with .wav files.
In theory, it would be nice to have a pure managed FLAC implementation.
There is a Java FLAC port, jFLAC, someday i might port it to C#.
Or maybe there is a way to make native code work under MONO. Any experts around?
If this is not possible, then using external compresors/decompressors might do the trick.
Would be nice if someone could point me to a public linux server where i could test this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Joey B on 2009-02-12 20:03:39
Is there a tutoral or any kind explanation of how to use Cuetools ?

I would like to write my files to a different directory using "artist - album" as the folder name and "artist - album" as the name of my single file .wav .

Your program is great !!!!

Joey B.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-02-12 20:09:06
Use the "Own format" textbox.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-12 23:17:28
Is there a tutoral or any kind explanation of how to use Cuetools ?

Not really. Just a readme file and a small wiki page (http://wiki.hydrogenaudio.org/index.php?title=CueTools) here, which i hope somebody will expand a bit - i'm not really good at this.

I would like to write my files to a different directory using "artist - album" as the folder name and "artist - album" as the name of my single file .wav .

Choose "Use custom format" for output path, and set it to something like "C:\Music\%D - %C\%D - %C.cue".
Make sure that in advanced settings "Single format" is set to %F and "Keep original filenames" is turned off. I think it's this way by default.

Your program is great !!!!

Actually, it's Moitah's program. I just added some new features.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lostnfound on 2009-02-13 18:08:57
Does anyone know how to change CueTools language? It's a good idea to place this info to readme :-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-02-13 18:14:56
AFAICS it is taken from the system?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-13 21:36:22
Yep...
If your system's language is russian or german, CUETools will use the appropriate language files, unless you remove the deDE and ruRU folders.
No other language packs available currently. If you are willing to help creating one of them, let me know.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rpp3po on 2009-02-13 23:21:55
If it hasn't been reported, yet: ALAC input does not work without cuesheets for 1.9.3. It displays the following message "Padded some input files to a frame boundary.", fails to detect the correct disc ID, and returns before verification. If I convert the same set of ALAC files to FLAC in Foobar and feed them into CUETools again everything works fine.

I tried the same in 1.9.4a. Here verification starts (I guess the disc ID has been detected then) but breaks when going from track 01 to track 02 with the following error: "Samples read != Samples expected".

Edit: ALAC files were created using XLD (Apple's Core Audio converter), so they should be conforming to specs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-02-14 09:33:44
In November last year I did a request for a drag & drop for the cue-sheet creator. A few days later I said I didn't need it any more.
But now I think it would be a nice feature.

Since the request of Fandango on Jan, 9 an update also calculates the crc's with and without zero's while only verifying.
Could this be made into a selectable feature?
I check many downloads without log, and now I have to wait until cuetools has calculated all crc's instead of telling me right away the disc is not in accurate rip database.

To finish a question about a log:
Code: [Select]
[Disc ID: 00376db3-03ea51a9-5f0f8019]
Track [ CRC    ] Status
 01 [41810bc1] (00/00) No matches
 02 [b38f9541] (00/02) No matches
 03 [f534d0a5] (00/02) No matches
 04 [70e38582] (00/02) No matches
 05 [b9ffa57c] (00/02) No matches
 06 [a4c21713] (00/02) No matches
 07 [a9e42b24] (00/02) No matches
 08 [2ce3ec1f] (00/02) No matches
 09 [691da940] (00/02) No matches
 10 [653ff6e2] (00/02) No matches
 11 [8a6e4f7c] (00/02) No matches
 12 [28bb673f] (00/00) No matches
 13 [67633e1d] (00/02) No matches
 14 [543b0503] (00/02) No matches
 15 [e08a56d5] (00/02) No matches
 16 [ab61a706] (00/00) No matches
 17 [27fd191b] (00/02) No matches
 18 [47a1b9a8] (00/02) No matches
 19 [875f8b51] (00/02) No matches
 20 [984f5c0a] (00/02) No matches
 21 [c1d8633a] (00/02) No matches
 22 [ca8cc11e] (00/02) No matches
 23 [3bb02914] (00/02) No matches
 24 [d7980cae] (00/02) No matches
 25 [04d0fc4c] (00/02) No matches
Offsetted by 450:
 01 [eae7aa77] (00/00) No matches
 02 [190770ed] (02/02) Accurately ripped as in pressing(s) #1
 03 [3de8c8b7] (02/02) Accurately ripped as in pressing(s) #1
 04 [8db62dac] (02/02) Accurately ripped as in pressing(s) #1
 05 [8215c9da] (02/02) Accurately ripped as in pressing(s) #1
 06 [331c07eb] (02/02) Accurately ripped as in pressing(s) #1
 07 [9a6d6c68] (02/02) Accurately ripped as in pressing(s) #1
 08 [97a0f8eb] (02/02) Accurately ripped as in pressing(s) #1
 09 [a1f2a00c] (02/02) Accurately ripped as in pressing(s) #1
 10 [50af46dc] (02/02) Accurately ripped as in pressing(s) #1
 11 [6499de26] (02/02) Accurately ripped as in pressing(s) #1
 12 [8aca015d] (00/00) No matches
 13 [02e24079] (02/02) Accurately ripped as in pressing(s) #1
 14 [f10f0f87] (02/02) Accurately ripped as in pressing(s) #1
 15 [3fceacb1] (02/02) Accurately ripped as in pressing(s) #1
 16 [29c0ff10] (00/00) No matches
 17 [b9bf2dd9] (02/02) Accurately ripped as in pressing(s) #1
 18 [3d7cde7c] (02/02) Accurately ripped as in pressing(s) #1
 19 [019b2343] (02/02) Accurately ripped as in pressing(s) #1
 20 [57d3d30c] (02/02) Accurately ripped as in pressing(s) #1
 21 [fee1fed6] (02/02) Accurately ripped as in pressing(s) #1
 22 [1731c90a] (02/02) Accurately ripped as in pressing(s) #1
 23 [dcd59316] (02/02) Accurately ripped as in pressing(s) #1
 24 [f286eafc] (02/02) Accurately ripped as in pressing(s) #1
 25 [a764d748] (02/02) Accurately ripped as in pressing(s) #1

Am I correct when I conclude that tracks 1, 12 & 16 haven't been ripped by both contributors?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2009-02-14 19:11:17
Since the request of Fandango on Jan, 9 an update also calculates the crc's with and without zero's while only verifying.
Could this be made into a selectable feature?
I check many downloads without log, and now I have to wait until cuetools has calculated all crc's instead of telling me right away the disc is not in accurate rip database.

To finish a question about a log:
...
Am I correct when I conclude that tracks 1, 12 & 16 haven't been ripped by both contributors?


I have the same problem with log files. I don't see any value in wasting time calculating CRC values only to eventually be told that the CD does not exist in the AccurateRip database.

Tigerman, are those three tracks really short tracks? I've seen 00/00 with tracks that are just a few seconds long.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-02-14 21:20:28


To finish a question about a log:
...
Am I correct when I conclude that tracks 1, 12 & 16 haven't been ripped by both contributors?


Tigerman, are those three tracks really short tracks? I've seen 00/00 with tracks that are just a few seconds long.


All 3 tracks are more than 2:30 minutes long.  I also think it's a bit strange that 2 persons rip all tracks but 3 and on top pf that, the same 3.
But I don't know another explanation for this log.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2009-02-17 08:31:51
Since the request of Fandango on Jan, 9 an update also calculates the crc's with and without zero's while only verifying.
Could this be made into a selectable feature?

+1, please add a checkbox to disable this feature of 1.9.4a.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-02-17 14:46:43
What's ru-RU\CUETools.resources.dll for? If it is a localization, how can I enable it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-02-17 15:29:01
If your system language is ru-RU, it is enabled automatically.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Steve Forte Rio on 2009-02-17 16:56:28
How can I save the log with summary results including information how many tracks are accuratly ripped???
I have flac files + cue and cue tools shows me this:

Code: [Select]
[Verification date: 17.02.2009 18:48:00]
[Disc ID: 00236e9b-0148dca1-be129a0c]
Track [ CRC    ] Status
 01 [900ed963] (04/08) Accurately ripped as in pressing(s) #1
 02 [fe14ff5a] (04/08) Accurately ripped as in pressing(s) #1
 03 [3251d1ea] (04/08) Accurately ripped as in pressing(s) #1
 04 [1ed5ba05] (04/08) Accurately ripped as in pressing(s) #1
 05 [6988026b] (04/08) Accurately ripped as in pressing(s) #1
 06 [63c0c74c] (04/06) Accurately ripped as in pressing(s) #1
 07 [502fbf53] (04/06) Accurately ripped as in pressing(s) #1
 08 [a1134504] (04/08) Accurately ripped as in pressing(s) #1
 09 [2a2a7ca5] (04/08) Accurately ripped as in pressing(s) #1
 10 [af9ffc79] (04/08) Accurately ripped as in pressing(s) #1
 11 [6e81ef45] (04/08) Accurately ripped as in pressing(s) #1
 12 [a096748a] (04/08) Accurately ripped as in pressing(s) #1
Offsetted by 658:
 01 [16bda481] (04/08) Accurately ripped as in pressing(s) #2
 02 [b4e5f384] (04/08) Accurately ripped as in pressing(s) #2
 03 [e91b7a6a] (04/08) Accurately ripped as in pressing(s) #2
 04 [e06ef381] (04/08) Accurately ripped as in pressing(s) #2
 05 [b948c587] (04/08) Accurately ripped as in pressing(s) #2
 06 [f3b8c9bc] (02/06) Accurately ripped as in pressing(s) #2
 07 [4b9e0fa3] (02/06) Accurately ripped as in pressing(s) #2
 08 [f4d7469e] (04/08) Accurately ripped as in pressing(s) #2
 09 [0eff3567] (04/08) Accurately ripped as in pressing(s) #2
 10 [a62f7475] (04/08) Accurately ripped as in pressing(s) #2
 11 [8df9bdff] (04/08) Accurately ripped as in pressing(s) #2
 12 [396b5720] (04/08) Accurately ripped as in pressing(s) #2

Track [ CRC32  ] [W/O NULL] [  LOG  ]
 -- [5BA4C51E] [69837F15]
 01 [ED14D67F] [0524FE8D] W/O NULL
 02 [9FFC6177] [A4439958] W/O NULL
 03 [84459ABA] [165623DE] W/O NULL
 04 [65AF8CCC] [6D42D10C] W/O NULL
 05 [2FE0C888] [E04A22A1] W/O NULL
 06 [9DA30EA6] [A38AB19E] W/O NULL
 07 [D651B2BB] [8F25F247] W/O NULL
 08 [5E96E749] [4AA61D43] W/O NULL
 09 [DC12FE56] [F67A5A90] W/O NULL
 10 [9C620694] [ACCAF361] W/O NULL
 11 [099A2D28] [69AB621E] W/O NULL
 12 [361F538B] [573BDEDA] W/O NULL
W/O NULL - what does it mean????

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Codebox.[/size]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-02-17 17:00:22
Without nullsamples, I guess?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Steve Forte Rio on 2009-02-17 17:10:56
it means that file not contain null samples??? or there must by CRC for this tracks without nullsamples??? I don't undderstand
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-02-17 18:17:40
There are two ways in which EAC can calculate CRCs.  This has no effect on the data that is ripped.

I take it the first pair listed is for the data as a single-file image?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-02-17 18:37:34
I take it the first pair listed is for the data as a single-file image?

Exactly.

Also, in the first column are CRCs from the audio with the null samples. In the second column are CRCs of the audio without the null samples.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-02-17 18:49:27
Thanks.

The null samples for CRC calculations applies to null samples (as a stereo pair) anywhere within the track, not just at the beginning or end.

Personally, I don't see the need to show the fourth column which I assume is a comparison against the log.  However, I'm curious to see what gets displayed if the checksums don't match at all or if they match a test CRC which may be different from a copy CRC.  I can pretty much figure this out for myself, but if you or anyone else can save me the trouble, I'd love to know.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-02-17 19:19:18
The null samples for CRC calculations applies to null samples (as a stereo pair) anywhere within the track, not just at the beginning or end.
Really? I wouldn't have thought so. It's a bit weird, does it have any practical advantage?

Personally, I don't see the need to show the fourth column which I assume is a comparison against the log.  However, I'm curious to see what gets displayed if the checksums don't match at all or if they match a test CRC which may be different from a copy CRC.  I can pretty much figure this out for myself, but if you or anyone else can save me the trouble, I'd love to know.
It doesn't compare the against the CRC in EAC's log, but maybe it is planned? Would be a nice feature to make an event from it that triggers something useful.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-02-17 19:37:13
Oh, I guess it just checks for that setting in the log?  That's even less useful.

Re: practical advantage
I can't think of any.  I despise the idea of leaving out null samples in CRC calculations.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Steve Forte Rio on 2009-02-18 08:59:05
Why CUETools don't shows the summary information like "9 tracks is accuratley riped. 1 track is not in database" ???
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-02-18 14:38:04
Oh, I guess it just checks for that setting in the log?  That's even less useful.

AFAIK it doesn't analyze the EAC log at all.

But I think this would be a great way of improving CUE Tools' performance... for example: only check rips where the log says the read offset correction was "0", in case you want to quickly "correct" all your older rips, only those without offset correction would be analyzed and if possible they'd be corrected. Utilizing the AR drive offset database for cross-reference would be nice, too, by using the drive model's string.

Then a EAC-log-rewrite feature... after correcting a rip's offset the EAC log gets rewritten to match the CRC/AR-CRCs, change the "no use of null samples" line if desired and of course change the offset correction line...

Rips where the CRC in the log doesn't match both CRCs calculated by CUE Tools, could be marked as suspicious, and so on. This could be useful for example after you've had an incident of data corruption due to hardware failure.

See, there's so much more that could be implemented in this tool just by integrating EAC log analyzing... so much work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2009-02-18 16:20:50
AFAIK it doesn't analyze the EAC log at all.


Yes, the EAC log file is analyzed now in 1.9.4 update 1. There is a pop-up window making you choose a log file -- even if there is only one EAC log file in the directory.

CUE Tools now always computes CRC values for all tracks and compares them to the EAC log file. It also computes CRC values for the entire CD. Here's an example:

[Verification date: 02/06/2009 8:09:59 PM]
[Disc ID: 001426c9-00bb266b-910a740c]
Disk not present in database.

Track    [ CRC32  ]   [W/O NULL]   [  LOG  ]
--      [D4B3D468]   [0941D83E]   
01      [90C6CBFC]   [E10369D8]     CRC32 
02      [03D82245]   [1B9DDD67]     CRC32 
03      [BCEF4981]   [264486A1]     CRC32 
04      [220D5D1A]   [C8631D4C]     CRC32 
05      [23971A5D]   [D20A87F2]     CRC32 
06      [FBEE9E98]   [26A4AF23]     CRC32 
07      [4DCD9046]   [B909E371]     CRC32 
08      [9FEB083A]   [3883A06F]     CRC32 
09      [BAE5C697]   [70AE19C0]     CRC32 
10      [2625C539]   [7F40B7A7]     CRC32 
11      [3F9E6356]   [B3F07038]     CRC32 
12      [AC331DC0]   [DEAD6636]     CRC32 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-19 11:02:50
12 [AC331DC0] [DEAD6636] CRC32
 
What a satanic track
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-19 11:09:48
it means that file not contain null samples??? or there must by CRC for this tracks without nullsamples??? I don't undderstand

Your files are ok. Each track is accurately ripped, as the log shows.
CRCs in the end of the log are only there to compare with EAC log file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-19 11:13:35
It doesn't compare the against the CRC in EAC's log, but maybe it is planned? Would be a nice feature to make an event from it that triggers something useful.

It is supposed to compare CRCs against the log.
If CRCs from the log match actual CRCs, the fourth column displays 'CRC32' message.
If CRCs from the log match actual CRCs without null samples, the fourth column displays 'W/O NULL' message.
If CRCs from the log don't match any of those, the fourth column displays CRCs from the log.
If CUETools was unable to parse the log file, the fourth column is empty.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2009-02-19 14:34:57
It is supposed to compare CRCs against the log.

If a CD is not in the AccurateRip database, I don't see any value in this and it just wastes time. Can an option be added so that CUE Tools goes back to the previous behaviour with "Verify, don't encode" when a CD is not in the AccurateRip database?

Previously, CRCs were only computed when a CD was in the AccurateRip database.

By the way, why does the "Select the best match" pop-up window appear to choose a log file when there is only one log file in a directory? The fully-qualified log file name is already shown and there is nothing else to choose in the drop-down list.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marconelli on 2009-02-19 14:40:03
It is supposed to compare CRCs against the log.
If CRCs from the log match actual CRCs, the fourth column displays 'CRC32' message.
If CRCs from the log match actual CRCs without null samples, the fourth column displays 'W/O NULL' message.
If CRCs from the log don't match any of those, the fourth column displays CRCs from the log.
If CUETools was unable to parse the log file, the fourth column is empty.


It seems that it works in English language logs only. Also, when CD is ripped to an image (so in log file there is only one CRC) it doesn't compare the CRCs. Anyway, (If you plan to continue development on log analyzing)  I think that it would be useful to check both CRCs in logfile (test CRC and copy CRC) - now it only compares copy CRC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-20 04:43:14
generating a cuesheet that is much more likely to be right than assuming the standard pregap using the offsets from freedb or musicbrainz is not so complicated.


I still don't understand how to make it useful. Most people don't keep disc id's in their rips. There's no standard on how to do his.
EAC puts discid in the cuesheet, but if we have the cuesheet then we already know the pregap.
I don't know any popular ripper which would store freedb/musicbrainz disc ids in tags.
Maybe dbpoweramp, but it also stores AccurateRipIds, so we don't need freedb to verify such a rip.
They might be added later by software such as picard tagger, but i don't see how it
could calculate them right when there's a non-standard pregap.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Joey B on 2009-02-20 17:17:56
Hi Gregory

What is filename corrector and what does it do ? I had some one song per file wav's with cue sheets that would not work in Winamp . Someone told me that ,he thought my filenames were wrong ,so I ran my files thru filename corrector and now they magically work in Winamp  . I would like to be able to explain it to Him .

Thank you

Joey B
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-21 01:13:04
Hi Gregory

What is filename corrector and what does it do ? I had some one song per file wav's with cue sheets that would not work in Winamp . Someone told me that ,he thought my filenames were wrong ,so I ran my files thru filename corrector and now they magically work in Winamp  . I would like to be able to explain it to Him .

Thank you

Joey B

Cue sheet is basicly a playlist, it contains the list of filenames and other information about the tracks - track names, gaps etc.
Often people convert their files from one filename to another, for example compress wavs to flac or decompress flac to wav.
Filenames have changed, but cue sheet didn't, so it doesn't play. Filename corrector updates filenames in the cue sheet to match
the files you actually have.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-23 04:18:32
Can an option be added so that CUE Tools goes back to the previous behaviour with "Verify, don't encode" when a CD is not in the AccurateRip database?

Previously, CRCs were only computed when a CD was in the AccurateRip database.

By the way, why does the "Select the best match" pop-up window appear to choose a log file when there is only one log file in a directory? The fully-qualified log file name is already shown and there is nothing else to choose in the drop-down list.


Done. Check out 1.9.5, it has two verify modes.

"Select the best match" pop-up window appears if there are several log files or log file name doesn't match cue sheet name.
You are asked to confirm that you want to use this log for verification/encoding.
In 1.9.5 it is a bit more informative and pretty
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ssjkakaroto on 2009-02-23 05:32:38
Thanks for the update Gregory!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2009-02-23 09:17:12
Done. Check out 1.9.5, it has two verify modes.

Thank you!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-02-28 20:19:03
I am having a problem and it must be something simple that I am overlooking. I can't read flac cue files or wright flac files. I get an "External program has thrown an exception" error.

If I convert the flac image to wav image and change .flac to .wav in the same cue file, it will read the wave image and convert it to anything but a flac file. Same error.

What am I missing????????
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-02-28 20:22:25
What am I missing????????

The old rule not to use more than one ? at a time. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-02-28 20:30:32
What am I missing????????

The old rule not to use more than one ? at a time. 

If you werrent a "Winamp addict", I'd take that personally. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-02-28 20:33:34
Ah, another Winampian?
Sorry then.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-02-28 22:13:40
I am having a problem and it must be something simple that I am overlooking. I can't read flac cue files or wright flac files. I get an "External program has thrown an exception" error.

If I convert the flac image to wav image and change .flac to .wav in the same cue file, it will read the wave image and convert it to anything but a flac file. Same error.

What am I missing????????

Maybe VC redistributable (http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en), but not very likely.
What's your OS and CPU?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-03-01 15:41:50
Maybe VC redistributable (http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en), but not very likely.
What's your OS and CPU?

Athlon processor and WinXP. tried VC2005 and VC2008 and no help.

Is there a way to log the error?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-01 16:24:09
Athlon processor and WinXP. tried VC2005 and VC2008 and no help.
Is there a way to log the error?

Not sure. I will probably make an option to disable MMX/SSE2 optimizations in FLAC in next version, we'll see if the problem is caused by processor-dependent optimizations.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-03-01 17:16:16
Not sure. I will probably make an option to disable MMX/SSE2 optimizations in FLAC in next version, we'll see if the problem is caused by processor-dependent optimizations.

Thank you! I will be watching for it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-03-01 23:16:18
FLAC encoding/decoding works for me with an Athlon XP 3200+. It supports MMX and SSE, but not SSE2. The oldest Athlon versions (before Athlon XP) support only MMX.


I've noticed that CUETools doesn't support cue sheets that contain only a single track. I have two albums that contain only one about an hour length track, Mike Oldfield's Amarok and Juno Reactor's Luciana. I may find a few more cue sheets with only one track when I start verifying my archived CD singles.

For example, here's the cue sheet from Amarok (ripped about 5 years ago with EAC):

Code: [Select]
PERFORMER "Mike Oldfield"
TITLE "Amarok"
FILE "Mike Oldfield - Amarok.ape" WAVE
  TRACK 01 AUDIO
    TITLE "Amarok"
    PERFORMER "Mike Oldfield"
    INDEX 00 00:00:00
    INDEX 01 00:00:12

This is the error message:

(http://i224.photobucket.com/albums/dd212/AB2K/ha/amarok.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: CrendKing on 2009-03-02 02:24:37
I tried the CUE Sheet Creator in CUETools. I browsed a directory with all MP3 or ape files. After clicking OK, nothing happens. How do I use it? Thanks in advance!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2009-03-02 07:27:16
@alex

I've got the Oldfield album with the same cuesheet and both versions of cuetools (193, 195) work as expected. Your problem relies in the runtime environment you are using.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-03-02 14:51:46
I've got the Oldfield album with the same cuesheet and both versions of cuetools (193, 195) work as expected. Your problem relies in the runtime environment you are using.


I already had installed all .Net versions and updates from MS. I just installed also the Visual C++ 2005 SP1 Redistributable package as instructed in the first post of this thread and rebooted, but that didn't help. I still get the same error message.

This PC has the above mentioned AMD Athlon XP 3200+ and the OS is XP Pro SP2.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-03-02 15:09:19
Not sure. I will probably make an option to disable MMX/SSE2 optimizations in FLAC in next version, we'll see if the problem is caused by processor-dependent optimizations.

I checked and the Athlon processor only supports MMX and not SSE. That is probably the issue. Could you build a version of the dll that only uses MMX and post it? It would be easier that modifying the program.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-03-02 16:45:16
The problem with "single track" cue sheets appear to exist only in CUETools v. 1.9.5.

I tested "1.9.2 u8", "1.9.3 u1", and "1.9.4 a". All three versions worked with the Amarok album.

Here's the log from "1.9.4 a":

Code: [Select]
[Verification date: 2009-03-02 17:37:27]
[Disc ID: 00041f6d-00083ece-020e1201]
Track    [ CRC    ] Status
01    [4e75c2e9] (07/11) Accurately ripped as in pressing(s) #1
Offsetted by 294:
01    [3c238f4f] (04/11) Accurately ripped as in pressing(s) #2

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
--    [6D8637F9]    [AD632F12]    
01    [2B1AD1AD]    [AD632F12]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2009-03-02 17:13:38
version 1.9.5 x86 produces the same log on my win 2K3 x64. I'm not using XP.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-04 21:16:32
I checked and the Athlon processor only supports MMX and not SSE. That is probably the issue. Could you build a version of the dll that only uses MMX and post it? It would be easier that modifying the program.

Please try the new build, setting DisableAsm=1 in settings.txt file (located in users\<username>\AppData\Roaming\CUE Tools. AppData might be a hidden folder, and might have a different name under XP)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marconelli on 2009-03-05 14:16:34
Hi Gregory

Thanks for the new feature - letting input pregaps directly from the interface. I find it very useful, because I have many old rips without cue and log files, so when my rip can't be found in accurate rip database, I try to find it with the most often used pregaps (00:00.32 and 00:00.33).

BTW... are you planning to add similar feature like in TripleFLAC - searching accurate rip db for different pregaps?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-05 15:57:37
I don't want to make Mr Spoon unhappy by putting too much stress on the database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-03-05 17:47:59
You could check musicbrainz or freedb/freedb2 to see if there's a submitted disc that has the same track sizes but a different pregap.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-03-05 19:17:15
I checked and the Athlon processor only supports MMX and not SSE. That is probably the issue. Could you build a version of the dll that only uses MMX and post it? It would be easier that modifying the program.

Please try the new build, setting DisableAsm=1 in settings.txt file (located in users\<username>\AppData\Roaming\CUE Tools. AppData might be a hidden folder, and might have a different name under XP)

You're a genius. It worked perfectly!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-05 23:36:29
You could check musicbrainz or freedb/freedb2 to see if there's a submitted disc that has the same track sizes but a different pregap.

In fact, i do. It already works, but not automaticly yet. If you select 'Freedb lookup' mode 'always' and try to convert, you can see the pregap in freedb entry - notice there's now a column with start offsets for each track. If the start offset for first track in nonzero, you can manually enter that pregap value in the main window.

I will probably somehow automate this process in the next version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2009-03-07 10:01:29
This compiles CUETools_1.9.5a CLI for Linux:

mkbundle2 ArCueDotNet.exe CUETools.Processor.dll taglib-sharp.dll HDCDDotNet.dll CUETools.Ripper.SCSI.dll CUETools.Codecs.dll CUETools.AccurateRip.dll CUETools.CDImage.dll UnRarDotNet.dll ICSharpCode.SharpZipLib.dll Bwg.Scsi.dll Bwg.Logging.dll Freedb.dll MusicBrainz.dll CUETools.Codecs.LossyWAV.dll CUETools.Codecs.ALAC.dll CUETools.Codecs.FLAC.dll CUETools.Codecs.WavPack.dll CUETools.Codecs.APE.dll CUETools.Codecs.TTA.dll -o ArCueTools

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zennon on 2009-03-08 21:52:36
I've been conducting regular checks of my 1700-odd rips against the AR database ever since the arcue scripts and executables became available, and have just begun using CUETools for this purpose - it's a very handy tool!!

I was surprised to find that the AR results from my latest check (7-8 March 09) were EXACTLY the same as those from a month ago, with the exception of one disc (Radiohead's "OK Computer"). I used to get significant jumps in the confidence levels, even if my checks were weeks apart. Has the AR database been closed for submissions, is CUETools querying it differently from the arcue script, or did I miss something altogehter?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-08 22:02:24
CUETools is doing it exactly the same way as arcue, i.e. it currently has no cache.
As far as i know, submissions to the database are not immediate.
Looks like it's updated every month or two.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-08 22:16:18
Hi everyone,
I have a request: could you plz add the support of .ogg in the filename corrector.

I know it may sound strange at first but let me explain:
I store all my rip as CDImage.flac+cue, soon my HDD will be full again & I have already 6 HDD (2,5TO), so I will not buy another HDD.
I know it is not the good storage strategy as each time I buy a new HDD I promise myself this is the last one ...
For storage, I like using CDImage+cue with F2K on my computer. I only use separated files for my personnal "Best Of" folder with my favorite songs which I use both on my computer & my DAP.
But If I really favor CDImage+cue over splitted files for archive, I don't care anymore if the image is lossless or lossy. So I plan mix both: lossless CDImage for my favorite albums & lossy CDImage for the rest of my collection in order to save space. I don't want to be forced to used joined files with lossless & splitted files with lossy like everyone is doing. I want to use CDImage for both lossless & lossy.

For a long time I have considered using lossyflac+cue as I could split & join it as I wanted & didn't needed to fix the cue manually (lossyflac works with cuetools as it's flac), but I finally changed my mind when I realized that I would never need to rejoin my splitted vorbis files because I would always keep my lossy CDImage.ogg+cue anyway. So I only needed perfect splitting.
So I decided to use aotuv at q4 as CDImage & split for my DAP with MusiCutter(vcut), which cuts CDImage.ogg with a cue like a charm. (Sample Accurate & keeps Vorbis's Vendor String)
My only problem now is that if I encode 100 CDImage.flac to CDImage.ogg, I must edit manually each .cue to fix the extension which is a pain.
I am almost certain that this is a very easy feature to add, it is just that nobody except me uses this strategy so far. FUD is usually enough to prevent people from doing what I intend to do.

So could you plz allow the filename corrector to support lossy CDImage plz (specially vorbis),
If you don't want to allow it by default just make an option for it.

Except the fact that this is not an usual way of storage, there is no reason not to allow it, CDImage.ogg plays just as well as CDImage.flac in F2K & it split losslessly with MusiCutter(vcut) so you can always get your tracks out of it. Almost as if you ripped them as separate ogg in the the first place. This storage strategy only needs a batch extension corrector to be 100% easy.

I hope you will understand my point of view & that you are not one of those purist who will tell me that I create dirty or non-compliant .cue with my CDImage.ogg thing. Thks.

Edit1: Question
I tried another tool called InTheCUE for this job which worked but was also changing WAVE to OGG inside the .cue, which broke the playback in F2K, so I ask the question as I guess you are a cue specialist, what is valid with CDImage.ogg+cue:
FILE "CDImage.ogg" WAVE which work in F2K or FILE "CDImage.ogg" OGG which is broken in F2K ???
I guess the guy who created the tool used FILE "CDImage.ogg" OGG as an imitation of FILE "CDImage.mp3" MP3 ... but I don't know if he was right, as F2K/MusiCutter don't work when you do that.

Edit2:
Indeed I don't ask for full support which would be stupid, just support within the filename corrector (& even optionnal if you wish).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: 2E7AH on 2009-03-08 22:56:00
if i understand you right:
when you are converting with foobar from flac to ogg image (generate multi-track file) then you'll get ogg image with all the cue info stored in vorbis comment
also if you need separate cue file you can use foo_cuesheet_creator and output it
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-08 23:03:55
absolutly not, I don't used embedded cuesheet at all ... I don't know why but I was pretty sure that I would be misunderstood ... I only want the filename corrector to find my CDImage.ogg, last time I tried to fix the broken link between a .cue & a .ogg, cuetools couldn't locate my lossy CDImage.ogg as ogg wasn't supported I guess.

in fact I am convinced that much more people would use lossy CDImage if the support for it was better ... I think anyone using lossless CDImage+cue because they don't like to tag&rename hundred of files, would naturally come to lossy CDImage+cue sooner or later ... it's a question of time (& money) before they run out of storage space.
It's only because sample accurate & clean splitting is not possible with every format/splitter that people fear that they will lose data or get corrupted files by doing it my way. With vorbis & the right tools, it really becomes an idiot fear. For a long time I was myself frighten of doing it this way ... I was telling myself I could not be right alone when everyone was doing it with splitted files ... I read HA since what ... 6 years maybe more, I have tested all codecs & all splitters around, now all the FUD is gone & I still like the idea of using CDImage.ogg+cue ... the only thing I need is a bach filename corrector ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-08 23:28:18
My only problem now is that if I encode 100 CDImage.flac to CDImage.ogg, I must edit manually each .cue to fix the extension which is a pain.

Since 1.9.5, you can encode flac to ogg with CUETools, producing correct cue sheets from the start.
Nevertheless, i'll probably add lossy formats support to filename corrector.

I tried another tool called InTheCUE for this job which worked but was also changing WAVE to OGG inside the .cue, which broke the playback in F2K, so I ask the question as I guess you are a cue specialist, what is valid with CDImage.ogg+cue:
FILE "CDImage.ogg" WAVE which work in F2K or FILE "CDImage.ogg" OGG which is broken in F2K ???

Both are not valid from purist point of view, but WAVE is a lot better supported.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-08 23:38:13
Quote Gregory S. Chudov:
"Nevertheless, i'll probably add lossy formats support to filename corrector."
Thks a lot !!! I'll save a lot of time  I have high hopes.

PS: I promise I will not use it to encode my Pink Floyd collection to lossy
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zennon on 2009-03-09 20:43:26
As far as i know, submissions to the database are not immediate.
Looks like it's updated every month or two.


It would be great if Spoon could confirm this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-03-09 20:45:02
There's no need for him to repeat himself.  He's already said this is the case.

http://www.google.com/search?hl=en&saf...amp;btnG=Search (http://www.google.com/search?hl=en&safe=off&q=accuraterip+database+update+submission+how+long&btnG=Search)
http://forum.dbpoweramp.com/showthread.php?t=16475 (http://forum.dbpoweramp.com/showthread.php?t=16475)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2009-03-10 06:07:39
I hope you will understand my point of view & that you are not one of those purist who will tell me that I create dirty or non-compliant .cue with my CDImage.ogg thing. Thks.


OGG Vorbis supports chaining (chapters). You don't need a cue sheet unless you have a mad desire to store two files per CD. 

foobar2000 reads and writes chained OGGs natively. If you open a chained OGG it will appear as if you loaded separate tracks or via a cue sheet. You can also take any separate OGGs you may have right now and make them chained by simply concatenating them together with any software that allows pure file joining. Each track has its own set of tags.

If you need to pull out an individual track from a chained OGG, get oggsplit from rarewares.org and drop the chained OGG onto the oggplit.exe

When converting to chained OGG in foobar2000 you need to check "merge all tracks into one output file" in the converter. I've done the same thing you mention with thousands of OGGs, and not a single cue sheet has been necessary. I find it spectaculary convenient with box sets. On the outside a 4-CD box set appears as one lone OGG. Loaded in foobar2000, it looks as though I loaded all 4 CDs worth of tracks. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-10 11:23:49
Thks. I know about chained OGG, some joiner I tested created these kind of files. I just don't like it. As I use separate cue for lossless CDImage, I just want to go the same way for lossy CDImage. Only by habbit & for homogeneity. For the same reason I don't like embedded cue, I don't like chained vorbis. It fells unatural to me ... over complicated for no gain.
As you said, I do have a mad desire to store two files per CD ... even 3 as I always keep the EAC log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Surfi on 2009-03-10 11:30:30
..., I do have a mad desire to store two files per CD ... even 3 as I always keep the EAC log.
::

Me too!   

::
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-03-13 14:44:04
I have  feature proposal: skip transconding if (encoder and encoder version and quality settings) or (encoder and quality settings) of the file are identical to the ones set in CUE Tools. Maybe choosing which one of these three must be matched is necessary, too, in order to give users a maximum of flexability. And of course, being able to transcode no matter what should still be possible.

For example: wvunpack -ss could give this info "modalities: lossless, very high, extra-3". Now if CUE Tools is set to encode with very high and extra mode 3, the encoding should be skipped, if the user wants it to.

Reason is obvious: if you have already transcoded some audio files to your new desired codec and quality setting then skipping these files will speed up batch transconding the whole rest of your collection.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-03-13 19:38:15
Experimental version: 1.9.5a
* Problem with single-track albums fixed

Thanks Gregory,

It works correctly now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-22 17:11:56
Please, try out the new UI. Would be nice to see some screenshots from XP, if it works:), because i only tested it on Vista.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-03-22 17:14:43
I like it. 
(I'm on Vista here... classical skin, however.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-22 17:39:43
 ... I didn't test but I am not sure that I like the change. I will have to test. I used to do a lot of right clic "search music folder for .cue" then "drag & drop" lots of .cue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-22 17:40:17
tuxman: i assume this means i haven't broken the localization too much?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-03-22 17:44:32
Of course you have.
(Would you mind changing the strings in my translations accordingly, like adding new strings as "<value />", when updating everything? It would surely help me to keep an overview...)

Just working on an update.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-22 17:45:07
I didn't test anything but I didn't found the "filename corrector". I guess it's not here yet as it seems ok.

Thanks. I was mostly worried about the icons in the file brower, looks like they're ok.

Filename corrector is now a 'correct filenames' choice in the action list.
You can select a cue sheet and press 'go', or you can select a folder, enable 'recursive' and press go.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-03-22 18:02:13
When 2.0x64 will be available?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-22 18:07:15
When 2.0x64 will be available?

Done.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-03-22 18:10:56
Oh, thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-03-22 18:17:37
What's ru-RU\CUETools.resources.dll for? If it is a localization, how can I enable it?



If your system language is ru-RU, it is enabled automatically.


I have english windows vista ultimate sp1 x64 version with russian formats, location, keyboard languages and system locale turned on but still i can't make CUETools run with russian interface. What else should I do?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-22 18:20:48
Hmm, i will look into it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-23 09:17:29
Thank you for this piece of software it allready has proven quite usefull for me!
I have one issue thouh. Maybe it is intended but I'll ask anyway.

I have a lot of one file flac images with embedded cuesheet and embeded coverart. When transcoding these images to 'new' flac images the replaygain info gets lost.
This replaygain info is added to the embedded cuesheet by foobar2000 but it seems it is not copied over via cuetools.

I'm using CUETools 1.9.5 (X64) on Vista btw.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mhudson7 on 2009-03-23 14:57:38
When 2.0x64 will be available?

Done.

Loading cue sheet file grays out go button?  Loading folder works OK, however.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-23 15:30:28
Loading cue sheet file grays out go button?  Loading folder works OK, however.

If you selected 'Recursive', yes. Not very convinient, i guess. Hmm.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mhudson7 on 2009-03-23 17:16:14
Loading cue sheet file grays out go button?  Loading folder works OK, however.

If you selected 'Recursive', yes. Not very convinient, i guess. Hmm.

Well, of course...my duh!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-03-23 17:22:04
Can you make an option to show the results of the operation, not just restrained "done" when the process is complete?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-23 17:31:43
Can you make an option to show the results of the operation, not just restrained "done" when the process is complete?

You mean, brief accuraterip summary for each item in batch mode? I was going to do that.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-03-23 17:56:24
You mean, brief accuraterip summary for each item in batch mode? I was going to do that.
Exactly!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marconelli on 2009-03-23 21:39:06
Thanks for the new version, Gregory. This new user interface is really great! And now I can easily test my old rips burned to dvds, even the ones without cue files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-24 09:54:40
...
I have a lot of one file flac images with embedded cuesheet and embeded coverart. When transcoding these images to 'new' flac images the replaygain info gets lost.
This replaygain info is added to the embedded cuesheet by foobar2000 but it seems it is not copied over via cuetools.
I'm using CUETools 1.9.5 (X64) on Vista btw.
Gregory; Is the above intended behaviour?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-24 10:12:17
Yes and no. This has been there from the start. As i understand, the reason for that was that replaygain info might become wrong if offset is applied.
I didn't get my hands on it yet. Are there any objections on just keeping replaygain info? Does anybody even need an option to remove it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-24 11:00:14
In my quick ~10 files test the replaygain info seemed to be the same before and after. Also after offset correction.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-03-24 11:15:59
The worst case scenario would be a gapless DJ mix in which a track begins or ends with a very brief and loud "crash" and the rest of the track happens to be quieter. In theory it would be possible that this peak would be moved to another track when the offset correction is applied. I doubt that would be a practical problem though. In any case you can always re-analyze the files if you think that's necessary.

So, yes, I think it would be good to preserve RG info when possible. It would be a green choice. Energy would not be used for unnecessary analysis processes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thelohocla on 2009-03-25 18:31:36
OK, just a simple question here. My library is composed of WavPack images w/ embedded cue sheets. When trying to accurip verify them, if I load them individually it works fine, but when trying to do a batch job it says something like "no supported format found". Does batch only look for external cue sheets, and is there any way around this?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-25 18:37:36
Which version are you using? This should work in 2.0
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thelohocla on 2009-03-25 18:42:47
Using 1.95a, I'll download 2.0 and try it. Thanks for the fast reply!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-03-26 11:37:57
Thanks for the new version. Maybe it's my computer but the new interface isn't working as I thought it would.
If I click on my computer icon to browse to another hard disk, I get a fault "onjuiste functie" (incorrect function) behind My computer.

Also I like to drag & drop from my total commander. This still works, but after every go, the input is changed to whatever directory is selected in the input tree.
This is a bit annoying because sometimes I want to check the same directory with different pregaps.
Is it possible to keep the last used directory in the input window?

P.S. I'm using 2.0 under Window XP pro, Dutch
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-26 15:28:10
Thanks for report. That's why this version was called 'preview'  That input tree works differently depending on OS and IE versions. Hopefully, this will be fixed in the final 2.0 release.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-03-26 17:11:09
Something's (obviously) wrong...

"Batch" and "Multiple" checkboxes are ticked on startup, but when I load a CUE sheet and click "Go", a message pops up ("Nothing selected."), and I'll have to untick the "Multiple" checkbox and tick it again.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-26 18:37:06
If you select 'multiple' or 'recursive', batch mode is activated.
When 'multiple' is checked, you have to select at least one album to process using checkboxes in the tree.
When you uncheck it and check it again, the current selected album becomes checked.
So far everything seems to function as designed. Or it doesn't?

Maybe the design is just too complicated.
I'm currently testing how would it work without the 'recursive' checkbox.
Batch mode would be activated when you select a folder.
Maybe the 'multiple' mode should go too?
It seems to cause a lot of confusion, but doesn't seem to be very useful.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-03-26 18:46:04
It doesn't work intuitively, at least...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-03-26 19:27:41
It took a few minutes of my time to test the new interface and learn to use it, but I think it works fine for me.

I have found the Multiple mode very useful. I don't think I can use the Recursive mode because I often have more than one cue file in each album folder and I need to select the correct cue sheets before running a batch.

It would be nice if I could prepare other folders while cuetools is running a batch (I mean creating dummy cue sheets and fixing the filenames inside cue sheets). Would it be possible to allow multiple instances?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-26 19:29:43
This is the first option in advanced settings.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-03-26 20:45:17
Oh, somehow I didn't notice it or stop to think what it means. Maybe "allow multiple instances" would have been clearer to me. I have seen that phrase in some other programs.

It seems to work fine. You have thought about everything. Thanks again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-26 23:29:06
Just a post to let you know that there is a cosmetic bug if you use 125% fonts in Windows XP SP2. I enlighted it in red in the screenshot.

(http://img230.imageshack.us/img230/7118/displaybug.png)

... it doesn't annoy me much as I can go back to normal fonts, but changing font size forces me to reboot ... so I just wanted to let you know in case it would be easy to fix.

I plan to switch to windows seven so it doesn't matter much anyway. Many programs have such bugs if you increase the fonts too much in XP, but at 125% it's usually OK. I don't have these bugs with any other programs at 125%.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-27 10:00:05
...I'm currently testing how would it work without the 'recursive' checkbox.
...Maybe the 'multiple' mode should go too?
It seems to cause a lot of confusion, but doesn't seem to be very useful.
What if multimode is allways on. Than you can still select a folder or more folders. And it is also possible to select a few or one file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bugs.Bunny on 2009-03-27 19:41:44
I've got ~600 cue sheets from EAC (noncompliant type) + ape files. I used the file name corrector that worked just fine. Now I have all my ape files tagged perfectly (dbpoweramp) but the Title and Perfomer Tags inside the cue sheets are not always correct. So I do want to update these fields from my ape tags.
I've once requested this:
http://www.hydrogenaudio.org/forums/index....st&p=609716 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=609716)
and in principle it does work. But I always need to let cue tools create a new cue sheet and beside this it seems that the stucture of the new cue sheet is a bit different from the original one (tried different cue style options).
What I would wish for is an additional option like "correct filenmes" eg "update title&performer" that only updates the performer and title tags of the selected cue sheets and leaves the rest of the cue sheet as it was.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: user44 on 2009-03-28 09:35:22
Always get error message: SHGetFolderLocation failed:

(http://img440.imageshack.us/img440/6995/capture1i.png)

Output saved to desktop regardless of entered Output Path.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-28 09:43:33
Bugreport:
CUETools 2.0 X64
Vista X64

I have an album that consists of 12 alac (.m4a) files. Creating a dummy cuesheet and verifing against accuraterip works as it should.
But when I try to verify & encode to flac with embedded cuesheet I get the following application error and cuetools crashes:
Exception: Index was outside bounds of the array.

cuesheet used:
Code: [Select]
REM COMMENT "CUETools generated dummy CUE sheet"
FILE "01 Death To Los Campesinos!.m4a" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "02 Broken Hearts Sounds Like Breakbe.m4a" WAVE
  TRACK 02 AUDIO
    INDEX 01 00:00:00
FILE "03 Don't Tell Me To Do The Math(s).m4a" WAVE
  TRACK 03 AUDIO
    INDEX 01 00:00:00
FILE "04 Drop It Doe Eyes.m4a" WAVE
  TRACK 04 AUDIO
    INDEX 01 00:00:00
FILE "05 My Year In Lists.m4a" WAVE
  TRACK 05 AUDIO
    INDEX 01 00:00:00
FILE "06 Knee Deep At ATP.m4a" WAVE
  TRACK 06 AUDIO
    INDEX 01 00:00:00
FILE "07 This Is How You Spell....m4a" WAVE
  TRACK 07 AUDIO
    INDEX 01 00:00:00
FILE "08 We Are All Accelerated Readers.m4a" WAVE
  TRACK 08 AUDIO
    INDEX 01 00:00:00
FILE "09 You! Me! Dancing!.m4a" WAVE
  TRACK 09 AUDIO
    INDEX 01 00:00:00
FILE "10 ...And We Exhale And Roll Our Eye.m4a" WAVE
  TRACK 10 AUDIO
    INDEX 01 00:00:00
FILE "11 Sweet Dreams, Sweet Cheeks.m4a" WAVE
  TRACK 11 AUDIO
    INDEX 01 00:00:00
FILE "12 [Bonus Track].m4a" WAVE
  TRACK 12 AUDIO
    INDEX 01 00:00:00

After using foobar2000 to create a flac image of the alac files cuetools (re)encode's the flac image fine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-28 15:38:18
But when I try to verify & encode to flac with embedded cuesheet I get the following application error and cuetools crashes:

Thanks. Does it only happen in 'Verify, then encode mode' and not in 'Encode and verify' mode? Do you have 'Fix offset if..' option turned on in advanced settings?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-28 17:19:38
More stable 2.0.1 release available, including several bugfixes & enhancements.
* Reads buggy ffdshow-encoded m4a's
* Filesystem tree should work now with older OS/IE versions
* You can remove 'user_profiles_enabled' file from the application folder to keep your settings in the application folder
* Batch verification now shows brief summary for each album
* Replaygain info no longer removed
* 'recursive' button removed. Batch mode is now activated by selecting a folder.
* Localization can be selected in the settings
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-03-28 18:21:55
One fine day I'll manage to resize the text labels correctly. 

Thanks for your quick update.
Still working great... and the new UI (the new button behavior) is a real improvement.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-28 18:43:55
Request:
Plz add an option in order for the audio data to NOT be automatically padded if you convert separate files+cue to CDImage+cue & data does end on a CD frame boundary. Because I recently grabbed the NINJA 2009 Tour Sampler (EP) which is a free flac download, as the files are splitted I decided to create a dummie cue & then join the files using cuetools. I do this because all my collection is backed up as CDImage+cue, so I don't want any of my file to be splitted. With cuetools I add an error message with my audio getting padded. It may be nice to fix bad CD frame boundary as Cuesheet are normally made for burning. But this is not a CD, this is an Original Electronic Format release (OEF) & I don't intend to burn it as my cue is just a playlist. So padding is annoying in this case.

As there was no option to disable padding, I was forced to reinstall an old version of foobar to do the job (foobar2000 V0.9 did the trick).

You may argue that it doesn't matter & but for Nine Inch Nails - 2008 - The Slip (which is in the same case, free splitted OEF release) there is two release 16Bits & 24Bits, as cuetools doesn't support 24Bits I cannot add padding the 24Bits version, so if I would add padding only the 16Bits version ... the timing would not be the same in the two versions which is an idea that I dislike much, because it is the same CD. Furthermore, I can always add padding later  to the 16Bits version if ever I would intend to burn it, so it is not nice to always force the padding IMHO. Finally as far as I understund padding add silence, I compared the foobar2000 & cuetools cuesheets, starting at track 3 the audio was shifted by 1 second (Edit: Mistake 1 frame only), so if it would be a gapless live album it would break the gaplessness, which is also an idea that I dislike. (Edit: not really true with only 1 frame which is 1 second/75)

I hope you understund what I meant
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-28 19:05:16
One fine day I'll manage to resize the text labels correctly. 

I doubt it, because i always spoil it  Don't worry, leave it to me. I intentionaly removed all size & position information from localizations, just forgot to resize the controls in the main resource.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-28 19:13:57
But this is not a CD, this is an Original Electronic Format release (OEF) & I don't intend to burn it as my cue is just a playlist. So padding is annoying in this case.

I'm afraid CUETools is not fit for such case. Too many features of CUETools depend on input being a real CD image.
CUE sheet format itself is not prepared to handle such images. Track offsets in CUE sheet are stored in format mm:ss:ff, where ff is the number of frames.
There's no way to store fractional track length in CUE sheet.
Sorry to dissapoint you, but i'm not planning to support non-cd contents in CUE Tools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-28 19:17:34
OK, so let's hope cuetools will support 24Bits one day so that I can fix both versions

Edit: My audio is shifted by 1 frame not by a 1 second. So it is 75 time less important than what I thought & due to this I begin to think that cuetools behaviour is the right way to handle this anyway ... so it's only a problem for my 24Bits version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-28 19:50:01
But when I try to verify & encode to flac with embedded cuesheet I get the following application error and cuetools crashes:

Thanks. Does it only happen in 'Verify, then encode mode' and not in 'Encode and verify' mode? Do you have 'Fix offset if..' option turned on in advanced settings?
Yes, I just found out it does not happen when in 'Encode and verify'! And yes, I have ´fix offset if...´turned on.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-28 19:55:24
Then it has been fixed in 2.0.1
Offset correction didn't work with .m4a

Personaly i find 'fix offset if' more and more useless.
Rip can be verified without changing offset, so there's usually no point in it.
You only loose some samples for no particular gain.
Especially in automatic mode, when it's not really predictable.
I.e. in your case the rip is perfectly alright as it is,
it makes no sense to apply an offset to make it similar to a more popular pressing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-28 19:59:32
Confirmed! Working with version 2.01.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-28 20:12:48
"fix offset if" doesn't make your rip any better but it gives you the "warm & fuzzy" felling of having the "best" rip possible, which secure ripping/accuraterip/lossless is all about. At least it can make your logs shorter ... personnaly I use "fix offset if" sometimes ... "fix offset if" is useless when you ripped the CD by yourself as you should be 100% that your pressing is official, you bought it, if you didn't rip it by yourself, it gives you the irrationnal feeling that you have a "more official pressing". This have nothing to do with audio quality, but I expect many many people will not agree if you remove it.

Edit: Typo
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-03-28 20:53:58
"fix offset if" doesn't make your rip any better but it gives you the "warm & fuzzy" felling of having the "best" rip possible, which secure ripping/accuraterip/lossless is all about.
I mean no disrespect, but this is complete nonsense.

Rip can be verified without changing offset, so there's usually no point in it.
I agree with you 100%

You only loose some samples for no particular gain.
This is exactly correct.  These can easily be "real" (non-null) samples usually not covered by AR, which apparently give people "warmies and fuzzies" as well.

Especially in automatic mode, when it's not really predictable.
Even more reason!

I.e. in your case the rip is perfectly alright as it is, it makes no sense to apply an offset to make it similar to a more popular pressing.
Hopefully this will appeal to the non-conforming conformists, in case no other sensible advice does.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-28 21:21:25
greynol:
Did I said that it was making sense ? I said exactly the opposite: "irrationnal feeling". If fixing offset in cuetools doesn't make sense, it doesn't make much more sense to fix it in EAC in the first place, that's what I meant. Offsets have always been for paranoid people. Accuraterip only underlines it. (Edit: must be my typo on felling==>feeling)

Gregory:
After some comparisons with audacity, I deleted my non-padded NIN OEF releases, thks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-03-29 07:11:13
I have a question, if the only thing that matters is the total number of accuraterip results no matter the offset, like you said here Answer 111 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=100&p=598687&#entry598687) why doesn't you show a summary of it in front of the logs ? Even if it makes them longer, it would make logs much more readable, because actually sometime tracks 1to5 are accurate according to offset X & tracks 6to10 are accurate according to offset Y, which is not really understandable for newbies & even when you get used to it, it's boring to have to browse all the results just to be sure that all track matches with at least one result somewhere within the log, no matter the offset. The presentation by offset is good & usefull, but IMHO there should be a summary of the total matches by track in front of the actual presentation sorted by offset. I hope accuraterip 2 will help having each track to match a particular offset. But has long as accuraterip logs will be so tricky to understand, a summary will save a headache to a lot of people IMHO.
I had to read back the 12 pages of this thread+accuraterip forum in order to start to understand how to interpret results where tracks from the same rip matches different pressings.

Also the .accurip extension is not really friendly as the windows XP search function will not search within it (unlike .log & .txt) so personnaly I have batch renamed all my .accurip to .accurip.txt in order to search within them. I guess you want to make them different from EAC . log & from basic .txt that is sometimes used like a .nfo, so why don't you use a double extension .accurip.txt. like lossywav .lossy.flac, I mean ... I read it with notepad & I actually already change the extension in order to make them searchable, so I would rather have them directly using .accurip.txt. It doesn't matter much anyway I will use .accurip.txt, in fact I already does, but it would just make my life easier. I mean: if there were both a summary in front of log & the log were saved has .accurip.txt. I could make right-clic with my mouse/search inside my .accurip.txt for "all tracks were ripped accurately" or "some tracks weren't ripped accurately" (as exemple of summary sentences within the log), & instantly sort my collection between accurate & non-accurate rips. It would be very easy. Actually, I can't search the log as the extension is unfriendly & also because there is nothing to search as there is no summary. (Edit: I know you use vista, so maybe you will not unsderstand my point of view, the crappy search function in of vista was one of the reason why I never switched to vista despite trying it for several weeks, you cannot really understand me if you don't know what you miss ...)

I hope you understand what I mean as my english is obviously not perfect. For me, it is obvious that you under-estimate the usefullness of the right-clic/search function. Removing the drag & drop filename corrector is an hint of this. I could right-clic search for .cue drag & drop, it was instantly done. No headache if settings were good. This mockup Answer 46 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=25&p=593177&#entry593177) was really what I wanted to see. Actually you can right-clic a folder full of EAC rips/search "There were errors" within .log & instantly find bad rips. I wish I could do the same as easyly with .accurip logs.

Last question, I noticed that "Partial match to pressing(s)" happens very often on the last track & my own ripping experience learned me that problem with scratches often happens on the last track too. Does it always means the rip is bad ? Is there any possibility that these rips could be good. I ask because I am gonna delete these rips to save some space. From my understanding of accuraterip these rips are inaccurate but I wonder if there could be some exception/special case that I could have forget. So I'd rather ask before I delete them. If you look at popular CD with lot of accurate results, the total is almost always lower on the last track.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-03-29 07:30:02
There are situations where ripping a disc can result in an error of repeated samples that causes all subsequent tracks to be offset by a constant amount.  Disregarding offsets in a summary can give a false impression that all but one track was ok.

I like the idea of configuring the name of the summary file (and it's location as well).  I too append .txt to the end and move it out of the subfolder where it was created.  Perhaps some of this has already been done.  I haven't upgraded for a little while.  It's pretty damn hard to keep up with all this killer development.  ("killer" is a good thing for those who aren't from my generation and part of the world, BTW).

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-03-29 11:17:13
Removing the drag & drop filename corrector is an hint of this.


I'm going to a party, so i'll answer to other questions later.

Drag&drop has not been removed from filename corrector.
I haven't decided yet how to hint to it from the interface, but you can drop a bunch of files to the filesystem tree.
All the things that this program can do now have a unified interface - you select a single file, a folder for batch processing, or use drag'n'drop to select a bunch of files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-03-29 11:47:25
Thanks for update,  filetree is now working in XP pro. 
But after dragging and dropping a directory, and do a (p.e.) correct filenames, the input is changed back to the directory in the tree.
So I have to drag and drop again to do a verify.
I would like if it stayed the dropped directory until I click in the tree.

Another point of convenience:
I store my albums in flac or ape files, most of my cue-files are based on wav-files.
It would be very handy if cuetools would apply 'correct filenames' if it encounters a cuesheet in which the extension doesn't match 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-03-29 21:39:27
Suggestion: If I pass a .cue file as a parameter to CUETools, it should be used automatically.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-03-30 15:10:49
Is it possible to extract the embedded cuesheets from a bunch of flac images via CUETools, without reencoding the whole file?
A friend of mine started using squeezecenter and that does not understand embedded cuesheets very well. So now I want to extract the cuesheets from these images. Afaik they are vorbis comments named CUESHEET.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fillip on 2009-03-31 10:10:18
hey there, I'm using 2.0.1 experimental and it turns out to work really good. no crash or bug happened till now  like the file tree. what I would request would be less interference with the existing tags (e.g. PUBLISHER turns into ORGANIZATION). and maybe the availability to just scan TAKs with embedded CUEs ... have a lot of old images here in TAK and I would like to check them against accuraterip
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 00:51:28
But as long as accuraterip logs will be so tricky to understand, a summary will save a headache to a lot of people IMHO.

The summary cannot be a simple yes or no anyway. But i will think what can be done.
Have you seen the summary in the batch mode? It shows a sum of confidence for all offsets.
I can add it to the .accurip logs.

I like the idea of configurable .accurip file name.

Last question, I noticed that "Partial match to pressing(s)" happens very often on the last track & my own ripping experience learned me that problem with scratches often happens on the last track too. Does it always means the rip is bad ? Is there any possibility that these rips could be good. I ask because I am gonna delete these rips to save some space. From my understanding of accuraterip these rips are inaccurate but I wonder if there could be some exception/special case that I could have forget. So I'd rather ask before I delete them. If you look at popular CD with lot of accurate results, the total is almost always lower on the last track.

There is one exception. If the last track is "partial match" in the pressing with high offset (usually 2000+), this just means that a few milliseconds of sound were lost at the end of the disc. This happens more often if your drive offset is high too. There always are some samples lost at the end, but AccurateRip ignores last 2940 samples, so we still get a match if drive offset + pressing offset were not that high.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 01:13:14
But after dragging and dropping a directory, and do a (p.e.) correct filenames, the input is changed back to the directory in the tree.

For now, i would sugest dropping it to a file tree instead of input text box.

I store my albums in flac or ape files, most of my cue-files are based on wav-files.
It would be very handy if cuetools would apply 'correct filenames' if it encounters a cuesheet in which the extension doesn't match 

You don't have to correct filenames if you are going to use this cue sheet in cuetools.
Just make sure "Advanced settings->Locate audio files if misisng" is turned on.
If you need to correct cue sheets for use with fb2k or something else, well, there's a 'correct filenames' action.
You want to automaticly modify cue sheets when verifying them? What's the point?
I prefer programs which are predictable, do what they are told to do, and don't try to be too clever.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 01:16:48
Suggestion: If I pass a .cue file as a parameter to CUETools, it should be used automatically.

Define 'used'.
Right now it puts it into input box, so all you have to do to actually use it is select an action and press 'go'.
I don't think running a random (previously selected) action immediately is a good idea.
Did you try "cuetools.exe /verify <file.cue>"?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 01:19:08
Is it possible to extract the embedded cuesheets from a bunch of flac images via CUETools, without reencoding the whole file?

Are there any objections to make it a part of 'create cue' action?
Right now it creates dummy cue sheets for file-per-track images, but what if it would also extract embedded cue sheets?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 01:29:40
what I would request would be less interference with the existing tags (e.g. PUBLISHER turns into ORGANIZATION). and maybe the availability to just scan TAKs with embedded CUEs ...

I'm afraid PUBLISHER turns into ORGANIZATION due to the lack of interference  It also depends on the player.
Tag mapping is a total mess (http://age.hobba.nl/audio/tag_frame_reference.html).
I just don't want to deal with it in cue tools, except for basic tags (Artist/Title/etc), which i handle through external taglibsharp.
The rest of the tags i just copy as they are. That means, that there's no interference when you convert flac to flac or ape to ape(wv,tak).
Your smart music player however can have it's own thoughs about tags mapping and give a different meaning to a tag with the same name, depending on the file format, which i personaly find insane.

TAKs with embedded CUEs were supposed to be supported, i'm afraid i've just broken it in 2.01  Oops.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 01:41:23
There are situations where ripping a disc can result in an error of repeated samples that causes all subsequent tracks to be offset by a constant amount.  Disregarding offsets in a summary can give a false impression that all but one track was ok.

Well, if we don't care about offsets and only care about the audio bits, all but one track are truly ok in this case
Especially if we view the album as a collection of tracks, not as solid image.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-01 02:18:11
Let's take an example that is tricky to understand for a newbie: this rip is accurate because all track matches to a CRC somewhere inside the log, but you cannot know that it is accurate as long as you don't take some precious time to analyse it. First the offset don't match, so for a newbie it seems inaccurate. Then when you realize that each track is accurate somewhere, you realize that there is no pressing in database where all track (which are all accurate somewhere) matches the same offset. Track 12 & 13 are specially tricky to understand. If there would be a summary of the total matches no matter the offset (like EAC does I think) with a short sentence of conclusion in front of the actual result sorted by offset it would much more easier to understand.

Code: [Select]
[Verification date: 26/03/2009 20:35:05]
[Disc ID: 002c9f58-02189834-ef124410]
Track [ CRC ] Status
 01 [3f2c9a5d] (00/71) No matches
 02 [7a2b32fe] (00/72) No matches
 03 [ba21c9d3] (00/74) No matches
 04 [caf89a47] (00/73) No matches
 05 [0f4ae166] (00/72) No matches
 06 [fdd1ffec] (00/72) No matches
 07 [5701a8a7] (00/71) No matches
 08 [77edd59f] (00/71) No matches
 09 [710af6d9] (00/70) No matches
 10 [0cc3909c] (00/71) No matches
 11 [2af70c17] (00/73) No matches
 12 [98b675df] (00/73) No matches
 13 [1e6be6e0] (00/72) No matches
 14 [06ab37c2] (00/71) No matches
 15 [12b42c24] (00/73) No matches
 16 [93847f7f] (00/67) No matches
Offsetted by 526:
 01 [55a6ecc1] (03/71) Accurately ripped as in pressing(s) #2
 02 [61d42d0e] (03/72) Accurately ripped as in pressing(s) #2
 03 [967b39e7] (03/74) Accurately ripped as in pressing(s) #2
 04 [b5948507] (03/73) Accurately ripped as in pressing(s) #2
 05 [80427398] (03/72) Accurately ripped as in pressing(s) #2
 06 [ca68582a] (03/72) Accurately ripped as in pressing(s) #2
 07 [ce1d9345] (03/71) Accurately ripped as in pressing(s) #2
 08 [9a20d591] (03/71) Accurately ripped as in pressing(s) #2
 09 [1fd46a5f] (03/70) Accurately ripped as in pressing(s) #2
 10 [926f6154] (03/71) Accurately ripped as in pressing(s) #2
 11 [1886ecff] (03/73) Accurately ripped as in pressing(s) #2
 12 [1c48d2fb] (03/73) Accurately ripped as in pressing(s) #2
 13 [f33c3520] (00/72) No matches
 14 [6c1e076a] (00/71) No matches
 15 [52c61e16] (00/73) No matches
 16 [18468c81] (00/67) No matches
Offsetted by 562:
 01 [9197ef79] (00/71) No matches
 02 [631546ee] (00/72) No matches
 03 [8a4ebb3f] (00/74) No matches
 04 [8c351787] (00/73) No matches
 05 [748602f4] (00/72) No matches
 06 [408fd5ee] (00/72) No matches
 07 [8d438049] (00/71) No matches
 08 [e864916d] (00/71) No matches
 09 [a862b093] (00/70) No matches
 10 [8b0940e4] (00/71) No matches
 11 [3b97117e] (00/73) No matches
 12 [5f9d0c95] (00/73) No matches
 13 [b9a5fc97] (03/72) Partial match to pressing(s) #2
 14 [1b74bb1a] (03/71) Accurately ripped as in pressing(s) #2
 15 [0e27b5f2] (03/73) Accurately ripped as in pressing(s) #2
 16 [aa9bdc3d] (03/67) Accurately ripped as in pressing(s) #2
Offsetted by 624:
 01 [4e28c97d] (68/71) Accurately ripped as in pressing(s) #1
 02 [8fe8f37e] (69/72) Accurately ripped as in pressing(s) #1
 03 [91c93673] (71/74) Accurately ripped as in pressing(s) #1
 04 [532d3047] (70/73) Accurately ripped as in pressing(s) #1
 05 [993340f6] (69/72) Accurately ripped as in pressing(s) #1
 06 [a87e83dc] (69/72) Accurately ripped as in pressing(s) #1
 07 [f2e85f97] (68/71) Accurately ripped as in pressing(s) #1
 08 [c483e32f] (68/71) Accurately ripped as in pressing(s) #1
 09 [5aad0d09] (65/70) Accurately ripped as in pressing(s) #1
 10 [e1d95e5c] (68/71) Accurately ripped as in pressing(s) #1
 11 [82576123] (70/73) Accurately ripped as in pressing(s) #1
 12 [ec896e32] (70/73) Partial match to pressing(s) #1
 13 [d23ebe95] (00/72) No matches
 14 [908a0d02] (00/71) No matches
 15 [6d4fc9b4] (00/73) No matches
 16 [7bf5e58f] (00/67) No matches
Offsetted by 660:
 01 [8a19cc35] (00/71) No matches
 02 [912a0d5e] (00/72) No matches
 03 [859cb7cb] (00/74) No matches
 04 [29cdc2c7] (00/73) No matches
 05 [8d76d052] (00/72) No matches
 06 [1ea601a0] (00/72) No matches
 07 [b20e4c9b] (00/71) No matches
 08 [12c79f0b] (00/71) No matches
 09 [e33b533d] (00/70) No matches
 10 [da733dec] (00/71) No matches
 11 [1bc963e9] (00/73) No matches
 12 [49fe0a7f] (00/73) No matches
 13 [3a099b36] (69/72) Accurately ripped as in pressing(s) #1
 14 [3fe0c0b2] (68/71) Accurately ripped as in pressing(s) #1
 15 [28b16190] (70/73) Accurately ripped as in pressing(s) #1
 16 [0e4b354b] (64/67) Accurately ripped as in pressing(s) #1

Track [ CRC32  ] [W/O NULL]
 -- [1EE5D6F8] [3FA0CF2E]
 01 [8D3C25ED] [9735BA9D]
 02 [CAD69A48] [86DA87A4]
 03 [3B823160] [86B00269]
 04 [F33ECAE3] [20CDDE60]
 05 [A38A856D] [06776367]
 06 [7A790E1C] [21369F0E]
 07 [83B74D2B] [E2D4B016]
 08 [49B7D546] [44D48885]
 09 [A1D45191] [BF682C61]
 10 [7CD2046A] [2ED76E23]
 11 [8A053B65] [53EFC9B1]
 12 [E07850DD] [9B74BA07]
 13 [C1791415] [01E27F3A]
 14 [4E675017] [7A5EBA97]
 15 [C5D95A38] [83036201]
 16 [D5F63E99] [817A1E4F]

Here is a mockup of the same log so that you understand what I mean:

Code: [Select]
[color=#FF0000][Verification date: 26/03/2009 20:35:05]
[Disc ID: 002c9f58-02189834-ef124410]
------------------------------------------------------------------
AccurateRip summary

Offsetted by (All offsets)
Track [ CRC ] Status
 01 [CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 02 [CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 03 [CRC of Actual Data] (Sum of total accurate rip for the track/74) accurately ripped (confidence X) no matter the offset/pressing
 04 [CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 05 [CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 06 [CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 07 [CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 08 [CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 09 [CRC of Actual Data] (Sum of total accurate rip for the track/70) accurately ripped (confidence X) no matter the offset/pressing
 10 [CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 11 [CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 12 [CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 13 [CRC of Actual Data] (Sum of total accurate rip for the track/72) accurately ripped (confidence X) no matter the offset/pressing
 14 [CRC of Actual Data] (Sum of total accurate rip for the track/71) accurately ripped (confidence X) no matter the offset/pressing
 15 [CRC of Actual Data] (Sum of total accurate rip for the track/73) accurately ripped (confidence X) no matter the offset/pressing
 16 [CRC of Actual Data] (Sum of total accurate rip for the track/67) accurately ripped (confidence X) no matter the offset/pressing
 
All tracks accurately ripped/No track could be verified as accurately ripped/Track XYZ couldn't be verified as accurately ripped. (You may have a different pressing than the ones in database)
----------------------------------------------------------------

No offset applied: (Actual Data)[/color]
Track [ CRC ] Status
 01 [3f2c9a5d] (00/71) No matches
 02 [7a2b32fe] (00/72) No matches
 03 [ba21c9d3] (00/74) No matches
 04 [caf89a47] (00/73) No matches
 05 [0f4ae166] (00/72) No matches
 06 [fdd1ffec] (00/72) No matches
 07 [5701a8a7] (00/71) No matches
 08 [77edd59f] (00/71) No matches
 09 [710af6d9] (00/70) No matches
 10 [0cc3909c] (00/71) No matches
 11 [2af70c17] (00/73) No matches
 12 [98b675df] (00/73) No matches
 13 [1e6be6e0] (00/72) No matches
 14 [06ab37c2] (00/71) No matches
 15 [12b42c24] (00/73) No matches
 16 [93847f7f] (00/67) No matches
Offsetted by 526:
 01 [55a6ecc1] (03/71) Accurately ripped as in pressing(s) #2
 02 [61d42d0e] (03/72) Accurately ripped as in pressing(s) #2
 03 [967b39e7] (03/74) Accurately ripped as in pressing(s) #2
 04 [b5948507] (03/73) Accurately ripped as in pressing(s) #2
 05 [80427398] (03/72) Accurately ripped as in pressing(s) #2
 06 [ca68582a] (03/72) Accurately ripped as in pressing(s) #2
 07 [ce1d9345] (03/71) Accurately ripped as in pressing(s) #2
 08 [9a20d591] (03/71) Accurately ripped as in pressing(s) #2
 09 [1fd46a5f] (03/70) Accurately ripped as in pressing(s) #2
 10 [926f6154] (03/71) Accurately ripped as in pressing(s) #2
 11 [1886ecff] (03/73) Accurately ripped as in pressing(s) #2
 12 [1c48d2fb] (03/73) Accurately ripped as in pressing(s) #2
 13 [f33c3520] (00/72) No matches
 14 [6c1e076a] (00/71) No matches
 15 [52c61e16] (00/73) No matches
 16 [18468c81] (00/67) No matches
Offsetted by 562:
 01 [9197ef79] (00/71) No matches
 02 [631546ee] (00/72) No matches
 03 [8a4ebb3f] (00/74) No matches
 04 [8c351787] (00/73) No matches
 05 [748602f4] (00/72) No matches
 06 [408fd5ee] (00/72) No matches
 07 [8d438049] (00/71) No matches
 08 [e864916d] (00/71) No matches
 09 [a862b093] (00/70) No matches
 10 [8b0940e4] (00/71) No matches
 11 [3b97117e] (00/73) No matches
 12 [5f9d0c95] (00/73) No matches
 13 [b9a5fc97] (03/72) Partial match to pressing(s) #2
 14 [1b74bb1a] (03/71) Accurately ripped as in pressing(s) #2
 15 [0e27b5f2] (03/73) Accurately ripped as in pressing(s) #2
 16 [aa9bdc3d] (03/67) Accurately ripped as in pressing(s) #2
Offsetted by 624:
 01 [4e28c97d] (68/71) Accurately ripped as in pressing(s) #1
 02 [8fe8f37e] (69/72) Accurately ripped as in pressing(s) #1
 03 [91c93673] (71/74) Accurately ripped as in pressing(s) #1
 04 [532d3047] (70/73) Accurately ripped as in pressing(s) #1
 05 [993340f6] (69/72) Accurately ripped as in pressing(s) #1
 06 [a87e83dc] (69/72) Accurately ripped as in pressing(s) #1
 07 [f2e85f97] (68/71) Accurately ripped as in pressing(s) #1
 08 [c483e32f] (68/71) Accurately ripped as in pressing(s) #1
 09 [5aad0d09] (65/70) Accurately ripped as in pressing(s) #1
 10 [e1d95e5c] (68/71) Accurately ripped as in pressing(s) #1
 11 [82576123] (70/73) Accurately ripped as in pressing(s) #1
 12 [ec896e32] (70/73) Partial match to pressing(s) #1
 13 [d23ebe95] (00/72) No matches
 14 [908a0d02] (00/71) No matches
 15 [6d4fc9b4] (00/73) No matches
 16 [7bf5e58f] (00/67) No matches
Offsetted by 660:
 01 [8a19cc35] (00/71) No matches
 02 [912a0d5e] (00/72) No matches
 03 [859cb7cb] (00/74) No matches
 04 [29cdc2c7] (00/73) No matches
 05 [8d76d052] (00/72) No matches
 06 [1ea601a0] (00/72) No matches
 07 [b20e4c9b] (00/71) No matches
 08 [12c79f0b] (00/71) No matches
 09 [e33b533d] (00/70) No matches
 10 [da733dec] (00/71) No matches
 11 [1bc963e9] (00/73) No matches
 12 [49fe0a7f] (00/73) No matches
 13 [3a099b36] (69/72) Accurately ripped as in pressing(s) #1
 14 [3fe0c0b2] (68/71) Accurately ripped as in pressing(s) #1
 15 [28b16190] (70/73) Accurately ripped as in pressing(s) #1
 16 [0e4b354b] (64/67) Accurately ripped as in pressing(s) #1

Track [ CRC32  ] [W/O NULL]
 -- [1EE5D6F8] [3FA0CF2E]
 01 [8D3C25ED] [9735BA9D]
 02 [CAD69A48] [86DA87A4]
 03 [3B823160] [86B00269]
 04 [F33ECAE3] [20CDDE60]
 05 [A38A856D] [06776367]
 06 [7A790E1C] [21369F0E]
 07 [83B74D2B] [E2D4B016]
 08 [49B7D546] [44D48885]
 09 [A1D45191] [BF682C61]
 10 [7CD2046A] [2ED76E23]
 11 [8A053B65] [53EFC9B1]
 12 [E07850DD] [9B74BA07]
 13 [C1791415] [01E27F3A]
 14 [4E675017] [7A5EBA97]
 15 [C5D95A38] [83036201]
 16 [D5F63E99] [817A1E4F]

With such a log you know instanly if all track are ripped accurately somewhere within the log, & even better you can instantly search all logs for bad rips. No headache with offsets & tracks 12 & 13.

Edit1: Thks for the answers.
Edit2: I wrapped logs in quote instead of code ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-04-01 02:26:54
I just got done telling you that there can actually be a problem with your rip in these instances and that picking results from one pressing and then from another can be misleading.

Do you think I'm making it up?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-01 02:29:29
Well maybe it's even more tricky than what I understund ... sorry but there is no tutorial anywhere.  I understund your repeated sample problem, but it seems to happen more often than "some situations" then ... because I only tested something like 20-30 rips & I already have 3-4 of these situations. Also if it was a random number of repeated samples how could it match any other pressing, the probability seems low IMHO. But well maybe I understund something wrong.

Edit: Typo mixed offset/sample
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-01 02:43:41
oh !!! I just catched that offset 526 & offset 562 are both tied to pressing number 2, I first thought that  offset 526 was one pressing & offset 562 another pressing, I understand better what you meant now Greynol, Thks !!! Damned, this make logs even harder to understand if there can be two offsets for the same pressing
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 02:51:16
The more i think about it, the more i'm convinced that audio-CD is a flawed technology from the start. It just isn't digital enough. Which is not surprising, considering that at the time this technology was being developed, noone really thought that computers would be able to read them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-01 03:10:13
Now that thks to greynol I understund this log better, I think that it shouldn't be reported this way, but this way:


Code: [Select]
[Verification date: 26/03/2009 20:35:05]
[Disc ID: 002c9f58-02189834-ef124410]
Track [ CRC ] Status
 01 [3f2c9a5d] (00/71) No matches
 02 [7a2b32fe] (00/72) No matches
 03 [ba21c9d3] (00/74) No matches
 04 [caf89a47] (00/73) No matches
 05 [0f4ae166] (00/72) No matches
 06 [fdd1ffec] (00/72) No matches
 07 [5701a8a7] (00/71) No matches
 08 [77edd59f] (00/71) No matches
 09 [710af6d9] (00/70) No matches
 10 [0cc3909c] (00/71) No matches
 11 [2af70c17] (00/73) No matches
 12 [98b675df] (00/73) No matches
 13 [1e6be6e0] (00/72) No matches
 14 [06ab37c2] (00/71) No matches
 15 [12b42c24] (00/73) No matches
 16 [93847f7f] (00/67) No matches
Offsetted by 526:
 01 [55a6ecc1] (03/71) Accurately ripped as in pressing(s) #2
 02 [61d42d0e] (03/72) Accurately ripped as in pressing(s) #2
 03 [967b39e7] (03/74) Accurately ripped as in pressing(s) #2
 04 [b5948507] (03/73) Accurately ripped as in pressing(s) #2
 05 [80427398] (03/72) Accurately ripped as in pressing(s) #2
 06 [ca68582a] (03/72) Accurately ripped as in pressing(s) #2
 07 [ce1d9345] (03/71) Accurately ripped as in pressing(s) #2
 08 [9a20d591] (03/71) Accurately ripped as in pressing(s) #2
 09 [1fd46a5f] (03/70) Accurately ripped as in pressing(s) #2
 10 [926f6154] (03/71) Accurately ripped as in pressing(s) #2
 11 [1886ecff] (03/73) Accurately ripped as in pressing(s) #2
 12 [1c48d2fb] (03/73) Accurately ripped as in pressing(s) #2
 13 [b9a5fc97] (03/72) Partial match to pressing(s) #2
 14 [1b74bb1a] (03/71) Accurately ripped as in pressing(s) #2 Offsetted by 562: Warning Offset mismatch
 15 [0e27b5f2] (03/73) Accurately ripped as in pressing(s) #2 Offsetted by 562: Warning Offset mismatch
 16 [aa9bdc3d] (03/67) Accurately ripped as in pressing(s) #2 Offsetted by 562: Warning Offset mismatch

Offsetted by 624:
 01 [4e28c97d] (68/71) Accurately ripped as in pressing(s) #1
 02 [8fe8f37e] (69/72) Accurately ripped as in pressing(s) #1
 03 [91c93673] (71/74) Accurately ripped as in pressing(s) #1
 04 [532d3047] (70/73) Accurately ripped as in pressing(s) #1
 05 [993340f6] (69/72) Accurately ripped as in pressing(s) #1
 06 [a87e83dc] (69/72) Accurately ripped as in pressing(s) #1
 07 [f2e85f97] (68/71) Accurately ripped as in pressing(s) #1
 08 [c483e32f] (68/71) Accurately ripped as in pressing(s) #1
 09 [5aad0d09] (65/70) Accurately ripped as in pressing(s) #1
 10 [e1d95e5c] (68/71) Accurately ripped as in pressing(s) #1
 11 [82576123] (70/73) Accurately ripped as in pressing(s) #1
 12 [ec896e32] (70/73) Partial match to pressing(s) #1
 13 [3a099b36] (69/72) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch
 14 [3fe0c0b2] (68/71) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch
 15 [28b16190] (70/73) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch
 16 [0e4b354b] (64/67) Accurately ripped as in pressing(s) #1 Offsetted by 660: Warning Offset mismatch


Track [ CRC32  ] [W/O NULL]
 -- [1EE5D6F8] [3FA0CF2E]
 01 [8D3C25ED] [9735BA9D]
 02 [CAD69A48] [86DA87A4]
 03 [3B823160] [86B00269]
 04 [F33ECAE3] [20CDDE60]
 05 [A38A856D] [06776367]
 06 [7A790E1C] [21369F0E]
 07 [83B74D2B] [E2D4B016]
 08 [49B7D546] [44D48885]
 09 [A1D45191] [BF682C61]
 10 [7CD2046A] [2ED76E23]
 11 [8A053B65] [53EFC9B1]
 12 [E07850DD] [9B74BA07]
 13 [C1791415] [01E27F3A]
 14 [4E675017] [7A5EBA97]
 15 [C5D95A38] [83036201]
 16 [D5F63E99] [817A1E4F]

There shouldn't be two offset results for the same pressing, what do you think of it ? It is possible to correct this offset lags ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 03:18:58
I'm afraid nothing is that simple
I've seen logs where 'pressings' get mixed up in the database.
As far as i remember, and example of that would be when one person rips for example 2/3 tracks successfully.
He would see the following log after database submission and update:

track1: (1/1) Accurately ripped as in pressing(s) #1
track2: (1/1) Accurately ripped as in pressing(s) #1
track3: (0/0) No matches

Then second person rips the whole disc successfully from other pressing.
He would see the following log after database submission and update:

track1: (1/2) Accurately ripped as in pressing(s) #2
track2: (1/2) Accurately ripped as in pressing(s) #2
track3: (1/1) Accurately ripped as in pressing(s) #1
Offsetted by xxx:
track1: (1/2) Accurately ripped as in pressing(s) #1
track2: (1/2) Accurately ripped as in pressing(s) #1
track3: (0/1) No matches
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-01 03:26:56
Hell, where is the logic of having the track 3 of the second ripper/second pressing  falling on pressing #1 of the first ripper ? the first ripper didn't even ripped this track !!!  Or did the number # of the pressing switched after the second submission maybe ??? This is an accuraterip design flaw ... I hope accuraterip 2 will fix this, I think I will stop using accurate rip as long as such bugs happens. I don't want to get crazy trying to understand this kind of things.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-01 05:27:08
Something that I still don't understand is why this problem (the one in my log) would prevent us from doing a "total match no matter the offset" summary. Because if this is just a drive lag that adds samples of silence. It doesn't really matter, this rip is still accurate, no ? I mean there must be a way to remove these samples of silence in order to fix this lag , no ?

Your problem with pressings getting messed is the same, the targetted pressing may not be accurate, but the track 3 itself is accurate, no ?

As far as I understand, there are two different problems in the end, first drives that introduced lags/silence samples, secondly the accuraterip database being unable to recognise a target pressing.

The second can be fixed by accuraterip V2.0 I think, but the first can only be fixed by shifting data in order to match a single offset instead of two (always the first one), it should be Cuetools's job, no ?

Also, if the added samples were really duplicated data instead of just silence, the CRC wouldn't match no ? If the CRC of the track match somewhere & the offset doesn't match at the same time, as far as I understund, it means it is added silence & not added data ... So if this is just an added silence issue that should be fixable, no ?

I may be stupid but there is something I still don't get, sorry

for example with this log:

Code: [Select]
[Verification date: 26/03/2009 20:41:43]
[Disc ID: 00250406-016d08c7-d310dc0d]
Track [ CRC ] Status
 01 [65103804] (00/44) No matches
 02 [880c6989] (00/49) No matches
 03 [afcc26e3] (00/45) No matches
 04 [ad5fffd6] (00/48) No matches
 05 [10a8aca8] (00/49) No matches
 06 [a61587d6] (00/49) No matches
 07 [a03ed93c] (00/49) No matches
 08 [25672619] (00/49) No matches
 09 [baff8a8d] (00/49) No matches
 10 [2565f4ee] (00/47) No matches
 11 [1a1da74c] (00/48) No matches
 12 [e8b25d28] (00/48) No matches
 13 [ec6a723b] (00/48) No matches
Offsetted by 48:
 01 [36898ee4] (11/44) Accurately ripped as in pressing(s) #3
 02 [10d48045] (12/49) Accurately ripped as in pressing(s) #3
 03 [4fcdbb54] (12/45) Accurately ripped as in pressing(s) #3
 04 [3c3946c8] (12/48) Accurately ripped as in pressing(s) #3
 05 [d00ef31a] (12/49) Accurately ripped as in pressing(s) #3
 06 [c36b43e6] (12/49) Accurately ripped as in pressing(s) #3
 07 [00d0ebec] (12/49) Accurately ripped as in pressing(s) #3
 08 [8318222a] (12/49) Accurately ripped as in pressing(s) #3
 09 [83082eb2] (12/49) Accurately ripped as in pressing(s) #3
 10 [9beb4a9a] (12/47) Accurately ripped as in pressing(s) #3
 11 [4d6928ed] (12/48) Accurately ripped as in pressing(s) #3
 12 [21d1f030] (12/48) Accurately ripped as in pressing(s) #3
 13 [1bcf0eab] (12/48) Accurately ripped as in pressing(s) #4
Offsetted by 898:
 01 [ed33781e] (04/44) Accurately ripped as in pressing(s) #4
 02 [85e7f147] (03/49) Accurately ripped as in pressing(s) #4
 03 [0918d581] (03/45) Accurately ripped as in pressing(s) #4
 04 [be7f65c6] (03/48) Accurately ripped as in pressing(s) #4
 05 [6ba5f8fa] (04/49) Accurately ripped as in pressing(s) #4
 06 [efa50f42] (04/49) Accurately ripped as in pressing(s) #4
 07 [b679c1a0] (04/49) Accurately ripped as in pressing(s) #4
 08 [d4ec5c97] (04/49) Accurately ripped as in pressing(s) #4
 09 [aa2c753c] (04/49) Accurately ripped as in pressing(s) #4
 10 [f2b9a2c6] (04/47) Accurately ripped as in pressing(s) #4
 11 [0fdf3889] (04/48) Accurately ripped as in pressing(s) #4
 12 [14f09bf2] (04/48) Accurately ripped as in pressing(s) #4
 13 [4dba0b95] (04/48) Accurately ripped as in pressing(s) #5
Offsetted by 1768:
 01 [823804ea] (23/44) Accurately ripped as in pressing(s) #1
 02 [d3b9f80e] (27/49) Partial match to pressing(s) #1
 03 [ef3fd34e] (24/45) Accurately ripped as in pressing(s) #1
 04 [4993dad6] (26/48) Accurately ripped as in pressing(s) #1
 05 [7e8f4033] (26/49) Accurately ripped as in pressing(s) #1
 06 [157f2020] (26/49) Accurately ripped as in pressing(s) #1
 07 [69ab88a6] (26/49) Accurately ripped as in pressing(s) #1
 08 [96183220] (26/49) Accurately ripped as in pressing(s) #1
 09 [f2eb2ec8] (26/49) Accurately ripped as in pressing(s) #1
 10 [8cd9bc31] (24/47) Accurately ripped as in pressing(s) #1
 11 [cad6ee29] (25/48) Accurately ripped as in pressing(s) #1
 12 [8df2a7f5] (25/48) Accurately ripped as in pressing(s) #1
 13 [68b99f03] (25/48) Partial match to pressing(s) #1,3

Track [ CRC32  ] [W/O NULL]
 -- [65D55916] [35665AD9]
 01 [A9636AF3] [7C5C5FA0]
 02 [F0B6C557] [E3E7D8D7]
 03 [7C431AE8] [31D8D380]
 04 [9FBA64A1] [76BCAFE3]
 05 [A05D79E0] [A06A4909]
 06 [E70669BD] [0EA9994B]
 07 [F850D617] [34BDFFE2]
 08 [7A91883F] [A4D7DC4F]
 09 [0A2AC3C3] [4DA10F98]
 10 [70FA3A12] [55268F82]
 11 [526790AB] [F8C96214]
 12 [40894DFD] [28DBE38F]
 13 [51A87217] [78DD6AB1]

If you offset track 13 alone by 48 & all the other tracks by 898, you should be able to end with a perfect pressing #4 ? no ? maybe I missed something & I am completly wrong, it's already not easy to understand when you are a native english, so when you are a foreigner I get headaches. Much sorry if I ask stupid questions ...
Something must be wrong with my way of thinking because if I were right track 13 from pressing #4 should have the same confidence as the other track of pressing #4 (3 or 4) but it doesn't as it have the same confidence as tracks from pressing #3 (11 or 12), something is not logic but I don't get what it is ... I know I must be wrong somewhere.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 05:53:51
I was just saying that pressing based (instead of offset based) representation, like you suggested, might be misleading. In my example it would look like that:

track1: (1/2) Accurately ripped as in pressing(s) #2
track2: (1/2) Accurately ripped as in pressing(s) #2
track3: (0/1) No matches
Offsetted by xxx:
track1: (1/2) Accurately ripped as in pressing(s) #1
track2: (1/2) Accurately ripped as in pressing(s) #1
track3: (1/1) Accurately ripped as in pressing(s) #1 offsetted by -xxx Warning offset mismatch

When in fact the rip is absolutely accurate.

As for your example, i don't quite understand what happens there too.
But i don't think you have extra samples, i think you have lost 36 samples.
And i think it happened somewhere on the border of tracks 12 and 13, but hard to say where exactly.
One offset says they are in track 12, other offset says they are in track 13.
The difference between them is 96 samples.
So assume those lost 36 samples are somewhere within those 96 samples.
That leaves 60 possible locations for them.
Interesting mathematical problem, but if i were you i wouldn't waste time on it.
I would just consider any rip where i cannot immediately interpret the log as "most probably inaccurate".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-01 06:14:13
> with no offset lag warning because there wouldn't be any offset difference within the same pressing in this case.
Nope.
You are forgetting that the third track in my example will only have a database entry in pressing #1, not #2.
Anyway, let's not depress new users too much with all those boring logs
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-04-01 07:22:25
Did you try "cuetools.exe /verify <file.cue>"?

No but I should... 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-04-01 11:09:15
Is it possible to extract the embedded cuesheets from a bunch of flac images via CUETools, without reencoding the whole file?
Are there any objections to make it a part of 'create cue' action? Right now it creates dummy cue sheets for file-per-track images, but what if it would also extract embedded cue sheets?
This would be perfect for me! Thank you in advance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-03 10:11:44
I have a cosmetic request, could you add a zero in front of number count when 100 is reached, in order that every result line get aligned on the right ? (maybe the new experimental version already does that, I didn't check)

04 [f7f61bc0] (61/225) Accurately ripped as in pressing(s) #2
05 [ec15c042] (160/226) Accurately ripped as in pressing(s) #2

01 [b583cf45] (14/99) Accurately ripped as in pressing(s) #6
02 [eca3e197] (15/100) Accurately ripped as in pressing(s) #6

04 [f7f61bc0] (061/225) Accurately ripped as in pressing(s) #2
05 [ec15c042] (160/226) Accurately ripped as in pressing(s) #2

01 [b583cf45] (14/099) Accurately ripped as in pressing(s) #6
02 [eca3e197] (15/100) Accurately ripped as in pressing(s) #6

Well it isn't aligned on my exemple but it should be in the log. I'm sure you get what I mean, you already do it for number from 1 to 9.

Edit:
Plz Gregory, remove the pressing #number, this information is worthless & caused me much trouble, only the offset matters.
See splitted discussion The pressing #number is useless (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=70948&view=findpost&p=625672), Thks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-04-04 06:26:56
Quote
Quote
(Tigerman @ Mar 29 2009, 13:47) *
But after dragging and dropping a directory, and do a (p.e.) correct filenames, the input is changed back to the directory in the tree.


(Gregory S. Chudov post Apr 1 2009, 01:13)

For now, i would sugest dropping it to a file tree instead of input text box.


Thanks for the tip, works great.
Would be nice if refresh (F5) worked in the tree.

Also thanks for the tip for locating missing audiofiles.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fillip on 2009-04-04 11:54:54
what I would request would be less interference with the existing tags (e.g. PUBLISHER turns into ORGANIZATION). and maybe the availability to just scan TAKs with embedded CUEs ...

I'm afraid PUBLISHER turns into ORGANIZATION due to the lack of interference  It also depends on the player.
Tag mapping is a total mess (http://age.hobba.nl/audio/tag_frame_reference.html).
I just don't want to deal with it in cue tools, except for basic tags (Artist/Title/etc), which i handle through external taglibsharp.
The rest of the tags i just copy as they are. That means, that there's no interference when you convert flac to flac or ape to ape(wv,tak).
Your smart music player however can have it's own thoughs about tags mapping and give a different meaning to a tag with the same name, depending on the file format, which i personaly find insane.

so ... foobar thinks the publisher Tag for FLAC means Publisher but for TAK it means Organization? that does sound a little bit insane
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-04-04 14:24:11
so ... foobar thinks the publisher Tag for FLAC means Publisher but for TAK it means Organization? that does sound a little bit insane

I think this is getting a bit off topic now, since Gregory already stated he doesn't want to mess with tag conversion... but looking at the chart he linked, the PUBLISHER tag field in Vorbis (FLAC) tags is there, but your FLAC files don't use it. So I t think the reason why you are having problems is because you really meant the ORGANIZATION tag field and not PUBLISHER in your Vorbis comment. If "PUBLISHER" turns into "ORGANIZATION" in foobar2000 after you've converted from FLAC to TAK, it can only mean that the original tag is ORGANIZATION and fb2k maps Vorbis/ORGANIZATION to PUBLISHER. But since CUE Tools names the APEv2 tag field ORGANIZATION (which doesn't officially exist as a standard?), foobar2000 will not remap it to PUBLISHER anymore when reading the APEv2 tag, for fb2k there is no official or unofficial standard APEv2/ORGANIZATION, so it displays it as is.

I'm not very happy that there are three different tag systems for lossless files, Vorbis, APEv2 and iTunes, and to a lesser degree Matroska. And that foobar2000 has a very transparent way of mapping things (so that the user doesn't see what is going on in the background), isn't helping either. Actually that's the main reason why I keep tagging as simple as possible and limit its use to the bare essentials, otherwise it means "a lot of work that will result in much more work once something goes wrong". I'm mainly frustrated about how Vorbis Comments do it so differently from what most of the rest of the lossless files do (APEv2). It just sucks.

PS: Suggestion - how about adding a new tab in the advanced settings that deals with tagging and creating of cue/log files? The "CUETools/General" section gets a bit crowded. All tagging and metadata related stuff should get its own tab, maybe unless it's more related to AR (writing AR log/tags settings should stay where they are?).

Also I can't figure out how to only write two tag fields when creating an embedded CD image: "CUESHEET" and "LOG". I let foobar2000 write all the other tag fields anyway.

And how do I disable writing of "ACCURATERIPID" to the tag and cue sheet, but still writing the AR log to a file?

What I currently do is to delete all tag fields except CUESHEET and LOG and then add another tag field with the contents of the accurip file to the tag, naming it ACCURIP. After that I'll load the audio file into foobar2000 and let it do the rest, which is actually only replaygaining the album.

I guess that when you ask 10 people how they like to tag their audio files then you will get 10 different answers. Do you think you can make the tagging more modular in some way? Have placeholders for certain key files (cue sheet, eac log, ar log) and placeholders for certain important metadata like the artist, album, year, and so on, but also AR results. Then people could create/edit/load/save profiles in CUETools. Certain tag field name standards or profiles could be hardcoded into CUETools in order to give newcomers some guidance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fillip on 2009-04-04 21:34:21
so ... foobar thinks the publisher Tag for FLAC means Publisher but for TAK it means Organization? that does sound a little bit insane

I think this is getting a bit off topic now, since Gregory already stated he doesn't want to mess with tag conversion... but looking at the chart he linked, the PUBLISHER tag field in Vorbis (FLAC) tags is there, but your FLAC files don't use it. So I t think the reason why you are having problems is because you really meant the ORGANIZATION tag field and not PUBLISHER in your Vorbis comment. If "PUBLISHER" turns into "ORGANIZATION" in foobar2000 after you've converted from FLAC to TAK, it can only mean that the original tag is ORGANIZATION and fb2k maps Vorbis/ORGANIZATION to PUBLISHER. But since CUE Tools names the APEv2 tag field ORGANIZATION (which doesn't officially exist as a standard?), foobar2000 will not remap it to PUBLISHER anymore when reading the APEv2 tag, for fb2k there is no official or unofficial standard APEv2/ORGANIZATION, so it displays it as is.

I'm using "Publisher=PUBLISHER" in the foobar standard-tag-field options and most of the time I created the tag, so that would mean that foobar creates ORGANIZATION instead of PUBLISHER but treats it as such in FLAC, but not for APEV2 tagging ... doesn't that seem unlikely?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-04-05 09:20:49
i appreciate this app and i dont mean to be an ass or anything but i totally dont like the direction the UI is going in for the new beta. 1.9.5a behaved better and it was much faster.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-05 10:02:38
I had some trouble with the new filename corrector in the beginning, I still think the old "drag & drop" was faster, so I still use 1.9.5a personnaly. I can live with the new one witch highlight the cue directory as a "radio button" when you drag & drop cue in it now. But I don't think it's of any use to highlight the cue directory in the tree, just to fix the filename within the cue. It's not handy when you drop hundreds of cue & it's slower. In the end, I think the new version targets other users (beginners) than the old version, so I would like to still have a place in the interface where I could drop .cue without caring for any setting & without having them selected in the tree. I don't like the new filename corrector but it still does the job so if Gregory likes it, I don't care I will use the old version simply. I think you're a little unfair with Gregory, he does quite a good job. Not everything is bad in the change, for exemple having the offset in "extra" instead of "advanced settings" is faster. So it greatly depends on what you use & how you use it.

For me the biggest actual problem is the display of the "fake pressing number" on the right within the accurip log, which make many tangled logs un-understandable if you don't have a degree in "cuetools logs exegesis". Actually I refrain myself from scanning my whole collection just because I want logs without those useless & missleading numbers & I don't want to re-scan my whole collection twice if ever they would get removed in the next version which I highly hope.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-04-05 10:15:01
i appreciate this app and i dont mean to be an ass or anything but i totally dont like the direction the UI is going in for the new beta. 1.9.5a behaved better and it was much faster.

We can only guess what exactly you don't like and how how the speed difference shows up. Your comment doesn't provide anything that would help Gregory in the development.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-04-05 10:40:23
For me the biggest actual problem is the display of the "fake pressing number" on the right within the accurip log, which make many tangled logs un-understandable if you don't have a degree in "cuetools logs exegesis".

I don't really understand what is going on when the tracks in the same album are "coming from" several different pressings even though they are all individually detected as accurate. Does that mean that I have an unsubmitted pressing in which some of the tracks have "skewed" differently than the other tracks?

However, personally, I would like to be able to see all possible information. Though some of the logs I have received have been quite odd, but maybe even these can help to understand a specific case better. Perhaps "full logging" could be an optional mode and the default mode could provide less information (something like EAC's AR component provides).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-05 10:51:37
It means nothing, the only way to detect a pressing is through its offset. This is not information, this is miss-information. The more different pressings (I mean CD with different offset) are submitted to the database the more this information is likely to be false (tangled), specially if the first guy who submitted result didn't rip all tracks or couldn't accurately rip some track. I don't know exactly how these numbers are generated, I think (guess) its related to the first submission for each offset. All I know is that I discovered that this information is wrong (tangled) several time.

This information looks like as if it is correct in most case only because most of the time, the first guy who rip the CD & submit, rips all tracks & rip them all accurately.
When this is not the case, (which happens quite often even if this is not the N°1 case) this information is wrong & means nothing. So overall as you cannot rely on it & it shouldn't be used.

Edit:
See this post to understand how this can happen: (Possible Explanation) (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=625021)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-04-05 11:29:42
I tried to understand the previous comments about this issue (also in the splitted thread on the CD Hardware/Software board) but I'm not sure if I succeeded.

It might help if Gregory could explain what part is provided directly by the database and what is calculated on the fly. Does the database hold the tracks from each different "pressing" together as a single "pressing" entity or are these pressing numbers created by CUETools?

Here is an example of my odd logs:

Code: [Select]
[Verification date: 2009-03-23 22:09:21]
[Disc ID: 00092e51-00300fb9-5608c006]
Track [ CRC    ] Status
 01 [9cb22a62] (00/78) No matches
 02 [6d301741] (00/79) No matches
 03 [3fc14c22] (00/80) No matches
 04 [8727ea13] (00/79) No matches
 05 [28c01b9b] (00/76) No matches
 06 [9d00ea66] (00/77) No matches
Offsetted by -582:
 01 [ad83ccbc] (14/78) Accurately ripped as in pressing(s) #2
 02 [20523f8d] (14/79) Accurately ripped as in pressing(s) #3
 03 [95c1e7a5] (14/80) Accurately ripped as in pressing(s) #3
 04 [2fc2af69] (14/79) Accurately ripped as in pressing(s) #3
 05 [fc043d57] (14/76) Accurately ripped as in pressing(s) #3
 06 [a78852eb] (14/77) Accurately ripped as in pressing(s) #2
Offsetted by -53:
 01 [fd689a4d] (08/78) Accurately ripped as in pressing(s) #7
 02 [d2be27cb] (08/79) Accurately ripped as in pressing(s) #7
 03 [edb4cdb1] (08/80) Accurately ripped as in pressing(s) #7
 04 [ea191ec9] (08/79) Accurately ripped as in pressing(s) #7
 05 [b7738654] (08/76) Accurately ripped as in pressing(s) #7
 06 [dfdfe135] (08/77) Partial match to pressing(s) #7
Offsetted by 68:
 01 [7c131b76] (16/78) Accurately ripped as in pressing(s) #1
 02 [ad493693] (16/79) Accurately ripped as in pressing(s) #2
 03 [b7a2c9cb] (16/80) Accurately ripped as in pressing(s) #2
 04 [883a71e8] (17/79) Accurately ripped as in pressing(s) #2
 05 [a4cb0293] (16/76) Accurately ripped as in pressing(s) #2
 06 [691fa4d2] (16/77) Accurately ripped as in pressing(s) #1
Offsetted by 74:
 01 [d8db5fba] (00/78) No matches
 02 [5b13d5bb] (00/79) No matches
 03 [7d4d1c94] (02/80) Partial match to pressing(s) #9
 04 [f56651c4] (00/79) No matches
 05 [caff77c9] (00/76) No matches
 06 [431ab8ef] (00/77) No matches
Offsetted by 81:
 01 [7ff523d4] (02/78) Accurately ripped as in pressing(s) #9
 02 [b9a6ffed] (02/79) Accurately ripped as in pressing(s) #9
 03 [7a579054] (00/80) No matches
 04 [2dceefb9] (02/79) Accurately ripped as in pressing(s) #9
 05 [03ab743f] (02/76) Accurately ripped as in pressing(s) #8
 06 [14c94cae] (02/77) Accurately ripped as in pressing(s) #9
Offsetted by 86:
 01 [bd100a21] (02/78) Accurately ripped as in pressing(s) #8
 02 [6b09c225] (02/79) Accurately ripped as in pressing(s) #8
 03 [10808ce5] (03/80) Accurately ripped as in pressing(s) #8
 04 [14e07201] (02/79) Accurately ripped as in pressing(s) #8
 05 [6bbe2931] (00/76) No matches
 06 [f27ed8cc] (02/77) Accurately ripped as in pressing(s) #8
Offsetted by 349:
 01 [b90545bb] (17/78) Accurately ripped as in pressing(s) #6
 02 [8b0cda86] (17/79) Accurately ripped as in pressing(s) #6
 03 [09e0b05a] (17/80) Accurately ripped as in pressing(s) #6
 04 [11552584] (17/79) Accurately ripped as in pressing(s) #6
 05 [567494d3] (17/76) Accurately ripped as in pressing(s) #6
 06 [33fe9a9d] (17/77) Accurately ripped as in pressing(s) #6
Offsetted by 369:
 01 [1565092e] (05/78) Accurately ripped as in pressing(s) #5
 02 [487f580c] (05/79) Accurately ripped as in pressing(s) #5
 03 [c7aa7ccd] (05/80) Accurately ripped as in pressing(s) #5
 04 [ab485c09] (05/79) Accurately ripped as in pressing(s) #5
 05 [1b660552] (05/76) Accurately ripped as in pressing(s) #5
 06 [c114b785] (05/77) Accurately ripped as in pressing(s) #5
Offsetted by 387:
 01 [bc4e18ec] (00/78) No matches
 02 [f14ec4f1] (00/79) No matches
 03 [49f717a1] (05/80) Partial match to pressing(s) #4
 04 [e6d597c9] (00/79) No matches
 05 [06f42509] (00/76) No matches
 06 [6414dc27] (00/77) No matches
Offsetted by 394:
 01 [593717f7] (05/78) Accurately ripped as in pressing(s) #3
 02 [e9b6c69c] (05/79) Accurately ripped as in pressing(s) #4
 03 [1a921d5a] (00/80) No matches
 04 [0ad10042] (05/79) Accurately ripped as in pressing(s) #4
 05 [372b4c98] (05/76) Accurately ripped as in pressing(s) #4
 06 [d8ad992a] (05/77) Accurately ripped as in pressing(s) #3
Offsetted by 537:
 01 [3d3aebba] (00/78) No matches
 02 [38ad56e8] (00/79) No matches
 03 [5820b831] (10/80) Partial match to pressing(s) #1
 04 [ca96438f] (00/79) No matches
 05 [37e1f4c6] (00/76) No matches
 06 [ea043cff] (00/77) No matches
More than 10 offsets match!

Track [ CRC32  ] [W/O NULL]
 -- [4A0FBF46] [2AED3505]
 01 [4E079B87] [E9C376E3]
 02 [88913FA4] [11DB04B0]
 03 [6EFE0C70] [D3B2611C]
 04 [3B7423DB] [3084F142]
 05 [57E9EBA1] [F6207931]
 06 [26E16D68] [1511D14D]
I ripped it seven years ago to a single file & cue sheet and I didn't have offset correction set in EAC (at that time I didn't have any of the listed reference dics). Usually I have also the EAC logs stored, but in this case it is missing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-05 11:39:08
Your rip is accurate, the problem is that if you would trust the #pressing information you would think the one "Offsetted by 349 tied to pressing #6" or the one "Offsetted by 369 tied to pressing #5" are the "best" ones, & you would reject the one "Offsetted by 68 which is tied to both pressing #1 tangled with pressing #2" & the one "Offsetted by -582 which is tied both to pressing #2 tangled with pressing #3"", this is NOT TRUE your CD could very well be  from the pressing "Offsetted by 68" or from the pressing "Offsetted by -582". In fact, it is even more likely that your CD is from the pressing "Offsetted by 68" or from the pressing "Offsetted by -582" than from the pressing "Offsetted by 369", because the accuraterip count is higher (14 or 17 Vs. only 5) so obviously these pressings have been sold much more.

A match is a match, all counts. All matches on the same offset is a complete pressing, all pressing counts too. The actual display exclude some perfectly accurate pressing.

So the pressing "Offsetted by 68" or "Offsetted by -582" are not worst than the pressing "Offsetted by 349" & "Offsetted by 369". It is just as accurate, which is very missleading due to the way it is displayed right now.

Edit: forgot the pressing "Offsetted by -582" which is good too
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-04-05 12:20:24
I'm going to post a few other logs that look suspicous.

Here's the first.
Code: [Select]
[Verification date: 2009-03-30 17:48:20]
[Disc ID: 000c56a6-005d0a96-75090d09]
Pregap length 00:00:32.
Track [ CRC    ] Status
 01 [3bcca92f] (19/29) Accurately ripped as in pressing(s) #1
 02 [82c425e1] (19/29) Accurately ripped as in pressing(s) #1
 03 [d2549a52] (19/29) Accurately ripped as in pressing(s) #1
 04 [33a116b6] (18/28) Accurately ripped as in pressing(s) #1
 05 [ff40280f] (19/29) Accurately ripped as in pressing(s) #1
 06 [cf15e913] (19/29) Accurately ripped as in pressing(s) #1
 07 [81538458] (19/29) Accurately ripped as in pressing(s) #1
 08 [2568846f] (19/28) Accurately ripped as in pressing(s) #1
 09 [4d06a4b6] (02/27) Accurately ripped as in pressing(s) #2

Track [ CRC32  ] [W/O NULL]
 -- [4019831C] [4F03B3DC]
 01 [3375127F] [BE1C3E54]
 02 [65FD20F7] [61605CCA]
 03 [46D5A689] [9A18CF9A]
 04 [555F7FE6] [D833D3B0]
 05 [FD9DB432] [5CFFBDF3]
 06 [86CC84B2] [FDBBDA9F]
 07 [0ACB623E] [631A4477]
 08 [DA7EDF71] [355118DE]
 09 [85A2F23D] [1CDCC758]
Apparently there is a different pressing that does not have a different offset and only the last track matches the tracks in this pressing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-05 12:25:55
It might be that the last track is a bonus track, no ?

Edit2: Well, no, I don't think so. For me this rip is accurate anyway & that's the only thing you should worry about. It might sound strange that 17 guy wouldn't be able to rip the last track, the only question you should ask yourself is: is it impossible ? the answer is no, specially as it is the last track & last track can have trouble for various reason. (Edge of CD scratched or big offset & over-read)

Edit1: IMHO there should be a dedicated thread for cuetools logs because I feel like everyone hijack this thread with his logs almost everyday.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-05 12:32:12
I guess most people had trouble ripping the last track.
Sorry, a bit busy at the moment.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-04-05 12:50:46
It might be that the last track is a bonus track, no ? (Edit: well no I don't think so.)

If would then be a different disc I think. Gregory is probably right.

EDIT

Though I still don't understand why the pressing #2 is not listed separately with its offset.

Quote
Edit: IMHO there should be a dedicated thread for cuetools logs because I feel like everyone hijack this thread with his logs almost everyday.

That depends on what is considered to be on topic here. Since some logs seem to be difficult to understand I think it is good to have a few different examples and explanations for them.

I assume the previous thread split was done because the discussion wandered a bit off-topic.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-05 13:00:56
Yes, Gregory is right. For me the second log shows how accuraterip thinks from a machine point of view, & not from our human point of view. If accuraterip tells you that it is this wrong then there is a logic way to understand it. Checksums are relentless, but again it shows that the #pressing numbers are meaningless. It only tells you that the first guy who ripped the CD failed on the last track ... what a usefull information

Your log wouldn't be less informative if it would look like this:

Quote
[Verification date: 2009-03-30 17:48:20]
[Disc ID: 000c56a6-005d0a96-75090d09]
Pregap length 00:00:32.
Track [ CRC ] Status
01 [3bcca92f] (19/29) Accurately ripped as in pressing(s) #1
02 [82c425e1] (19/29) Accurately ripped as in pressing(s) #1
03 [d2549a52] (19/29) Accurately ripped as in pressing(s) #1
04 [33a116b6] (18/28) Accurately ripped as in pressing(s) #1
05 [ff40280f] (19/29) Accurately ripped as in pressing(s) #1
06 [cf15e913] (19/29) Accurately ripped as in pressing(s) #1
07 [81538458] (19/29) Accurately ripped as in pressing(s) #1
08 [2568846f] (19/28) Accurately ripped as in pressing(s) #1
09 [4d06a4b6] (02/27) Accurately ripped as in pressing(s) #2

Track [ CRC32 ] [W/O NULL]
-- [4019831C] [4F03B3DC]
01 [3375127F] [BE1C3E54]
02 [65FD20F7] [61605CCA]
03 [46D5A689] [9A18CF9A]
04 [555F7FE6] [D833D3B0]
05 [FD9DB432] [5CFFBDF3]
06 [86CC84B2] [FDBBDA9F]
07 [0ACB623E] [631A4477]
08 [DA7EDF71] [355118DE]
09 [85A2F23D] [1CDCC758]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-05 13:53:14
Quote
Though I still don't understand why the pressing #2 is not listed separately with its offset.


Because it has the same offset & because it is the same pressing. As I tried to explain, #1 & #2 tells nothing except that ripper N°1 was the first guy who ripped the CD & he ripped track 1-8 accurately which were marked as pressing #1, then came the guy N°2 which ripped the CD accurately from track 1 to 9, as 1-8 were already marked as pressing #1, only the track 9 was marked as pressing #2. There is NOT two pressings.

This is a very missleading behavior for new users. Even knowing all this, in the first seconds, I was misslead thinking it might be due to a bonus track when I perfectly know that it would have a new ID if it would have a bonus track. So for a new user, this is just un-readable.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2009-04-05 16:51:30
It is likely that the drive is ripping the last track differently, (or was there an EAC bug a while back on some drives)? and 2 other people have the same drive & issue...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-05 17:19:24
As we are at strange logs examination, this one is not bad too, personnaly I don't understand how there can be such a huge confidence jump between tracks, even between tracks of the same pressing # number, it jumps up & down from 60 to 160 ... & not on the last track. It's a quite popular as it's a Bob Marley CD. If someone has a clue.


Code: [Select]
[Verification date: 03/04/2009 06:05:37]
[Disc ID: 00291c0e-01f054e3-c5115710]
Track [ CRC ] Status
 01 [c0683278] (62/227) Accurately ripped as in pressing(s) #1
 02 [2e767ef0] (62/232) Accurately ripped as in pressing(s) #3
 03 [340d0ef4] (62/227) Accurately ripped as in pressing(s) #2
 04 [f7f61bc0] (61/225) Accurately ripped as in pressing(s) #2
 05 [ec15c042] (160/226) Accurately ripped as in pressing(s) #2
 06 [12f9bb59] (62/228) Accurately ripped as in pressing(s) #2
 07 [5ce044d3] (169/227) Accurately ripped as in pressing(s) #1
 08 [513de00d] (169/225) Accurately ripped as in pressing(s) #1
 09 [6dbd6dbf] (159/228) Accurately ripped as in pressing(s) #2
 10 [fe4dacdc] (162/229) Accurately ripped as in pressing(s) #2
 11 [ac98df80] (171/228) Accurately ripped as in pressing(s) #1
 12 [e09118dd] (63/229) Accurately ripped as in pressing(s) #3
 13 [ee8ecbd5] (171/227) Accurately ripped as in pressing(s) #1
 14 [020bf2d0] (72/225) Accurately ripped as in pressing(s) #3
 15 [99099da6] (82/225) Accurately ripped as in pressing(s) #1
 16 [fc8e0a5b] (148/220) Accurately ripped as in pressing(s) #1
Offsetted by -664:
 01 [2138fa35] (05/227) Accurately ripped as in pressing(s) #5
 02 [2f810237] (05/232) Accurately ripped as in pressing(s) #7
 03 [c2e6cefd] (05/227) Accurately ripped as in pressing(s) #4
 04 [0cefda2d] (05/225) Accurately ripped as in pressing(s) #5
 05 [e2ff9a1b] (05/226) Accurately ripped as in pressing(s) #4
 06 [b606540a] (05/228) Accurately ripped as in pressing(s) #5
 07 [ce4c3ba7] (05/227) Accurately ripped as in pressing(s) #3
 08 [ae59f662] (05/225) Accurately ripped as in pressing(s) #3
 09 [f18c36d9] (05/228) Accurately ripped as in pressing(s) #4
 10 [49bab45c] (05/229) Accurately ripped as in pressing(s) #4
 11 [b1d5fba8] (05/228) Accurately ripped as in pressing(s) #3
 12 [38b1b338] (05/229) Accurately ripped as in pressing(s) #5
 13 [006c5060] (05/227) Accurately ripped as in pressing(s) #3
 14 [637e31bc] (05/225) Accurately ripped as in pressing(s) #5
 15 [dc72779b] (05/225) Accurately ripped as in pressing(s) #4
 16 [e65d55f3] (05/220) Accurately ripped as in pressing(s) #5
Offsetted by -96:
 01 [6ab0a297] (02/227) Accurately ripped as in pressing(s) #4
 02 [7d4164a1] (02/232) Accurately ripped as in pressing(s) #6
 03 [e90c074f] (00/227) No matches
 04 [1c9d6271] (00/225) No matches
 05 [d735b49e] (00/226) No matches
 06 [504e79d5] (00/228) No matches
 07 [6f18acea] (00/227) No matches
 08 [e3733a7a] (00/225) No matches
 09 [54118eb0] (00/228) No matches
 10 [567644c3] (00/229) No matches
 11 [ff77dddd] (00/228) No matches
 12 [4f8bbc30] (00/229) No matches
 13 [68cf3eb6] (00/227) No matches
 14 [9f17732b] (00/225) No matches
 15 [eef95ce2] (00/225) No matches
 16 [5a248e77] (00/220) No matches
Offsetted by 6:
 01 [42c6f153] (00/227) No matches
 02 [e3d3dbde] (00/232) No matches
 03 [c3513ff2] (00/227) No matches
 04 [bbaa0273] (00/225) No matches
 05 [3925935f] (00/226) No matches
 06 [374da903] (00/228) No matches
 07 [9c44472e] (00/227) No matches
 08 [d3564913] (00/225) No matches
 09 [cc47d4c1] (02/228) Accurately ripped as in pressing(s) #5
 10 [9f42a4dc] (00/229) No matches
 11 [cd15fc09] (00/228) No matches
 12 [70dea4d3] (00/229) No matches
 13 [aa87fd23] (00/227) No matches
 14 [b69e62f0] (00/225) No matches
 15 [973fb11c] (00/225) No matches
 16 [48a5fa54] (00/220) No matches
Offsetted by 10:
 01 [b4318618] (53/227) Partial match to pressing(s) #2
 02 [95c46804] (53/232) Partial match to pressing(s) #4
 03 [6d53d08d] (51/227) Partial match to pressing(s) #3
 04 [8000d736] (50/225) Partial match to pressing(s) #3
 05 [eb4a08db] (51/226) Accurately ripped as in pressing(s) #3
 06 [78b47cac] (53/228) Partial match to pressing(s) #3
 07 [f99d7f7d] (53/227) Accurately ripped as in pressing(s) #2
 08 [e0a0ecdd] (51/225) Partial match to pressing(s) #2
 09 [47e2b102] (52/228) Accurately ripped as in pressing(s) #3
 10 [01e3f387] (52/229) Accurately ripped as in pressing(s) #3
 11 [cd20f248] (52/228) Partial match to pressing(s) #2
 12 [e97b8e05] (52/229) Partial match to pressing(s) #4
 13 [8c0b992a] (51/227) Partial match to pressing(s) #2
 14 [9db4fc4e] (50/225) Partial match to pressing(s) #4
 15 [57fa151c] (50/225) Accurately ripped as in pressing(s) #3
 16 [b7a5bee3] (49/220) Accurately ripped as in pressing(s) #2

Track [ CRC32  ] [W/O NULL] [  LOG  ]
 -- [1A37DB61] [439E67C3] W/O NULL
 01 [DD2B55F2] [E0ED588B]
 02 [0081AF91] [4193E65E]
 03 [0106732F] [5ACBED08]
 04 [4F3F94CE] [C93AAD20]
 05 [218ABBCF] [0B8146F4]
 06 [3BD0E43B] [7A54B533]
 07 [35F586BD] [B6E6DBB9]
 08 [A6AE7349] [582E60E1]
 09 [7579B2D1] [1C33704A]
 10 [6F08BD5E] [033EEEA6]
 11 [9D02EBB7] [AC6DF490]
 12 [07AD8EBD] [42A87F01]
 13 [4A3112D6] [E57798EF]
 14 [4B1C1CE3] [1B14401D]
 15 [98B0FBAF] [1F0E527F]
 16 [9E89FEEE] [18753F8F]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2009-04-05 19:12:22
You would have to rip that CD in EAC of dBpoweramp to check those tracks out, to see if that jump is there.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-04-05 21:42:37
Alex B, is your drive configured as being able to overread in EAC?

Toggle the setting and see if you get a different result.

With some discs, the last two frames of non-null samples will be repeated due to a bug in EAC when overreading is disabled.  Because most people have this setting disabled, errant data will constitute the majority of submissions when this bug occurs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2009-04-06 20:14:27
Can an option be added so that CUE Tools goes back to the previous behaviour with "Verify, don't encode" when a CD is not in the AccurateRip database?

Previously, CRCs were only computed when a CD was in the AccurateRip database.

By the way, why does the "Select the best match" pop-up window appear to choose a log file when there is only one log file in a directory? The fully-qualified log file name is already shown and there is nothing else to choose in the drop-down list.


Done. Check out 1.9.5, it has two verify modes.

"Select the best match" pop-up window appears if there are several log files or log file name doesn't match cue sheet name.
You are asked to confirm that you want to use this log for verification/encoding.
In 1.9.5 it is a bit more informative and pretty


Thank you very much, Gregory. I've been using 1.9.5 since it came out (Feb 23) and today I upgraded to 1.9.5a (gee, I'm just over a month late now  ).

The log file issue has not been fixed (I have used 1.9.5 extensively and I just verified the problem on 1.9.5a). I specify "Verify AR only" but CUE Tools still prompts me for the name of the log file. I did not specify "Verify AR + CRCs" so the log file should not be required. Once "Verify AR only" has finished, the .accurip output file has the LOG column at the bottom completely filled in. I compared the .accurip output files for "Verify AR only" against "Verify AR + CRCs" and they are identical (except for the time of day, of course). Why do the two verify modes behave the same? If I specify "Verify AR only" I expect the CRCs in the log file as well as the log file itself to be ignored.

Nobody mentioned this so far, but I like the "CUE" icon you added in 1.9.5.

Ah, thank you for explaining the "Select the best match" pop-up window. I'll make sure my cue and log files have the same name. Yes, in 1.9.5 and 1.9.5a it is a bit more informative and pretty. Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: atzaus on 2009-04-07 19:23:01
I joined to ask what offset X, files accurately ripped means? Should my files be offset by 6 bits and then the will be accurately ripped? Is there an option to detect files as they are without offsetting them? Also can you add an option to generate a better formatted log for the folder so we can easily found out which folders are AR.
great work!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-04-07 19:53:21
Quote
Also can you add an option to generate a better formatted log for the folder so we can easily found out which folders are AR.


I strictly disagree with this as paths changes with time, maybe Artist/Album from freeDB, but no folder name & path, because some people have very strange way of naming their files.
All paths within EAC logs looks different for each guy, only the Artist/Album from freeDB in the first lines remains clean no matter the naming scheme. I am very happy with how it works right now, maths only no litteracy. Also if you add stuff like Folder: or Path: ... soon newbies will ask you to translate these & accurip logs will become less standardized.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: atzaus on 2009-04-07 21:37:18
Quote
Also can you add an option to generate a better formatted log for the folder so we can easily found out which folders are AR.


I strictly disagree with this as paths changes with time, maybe Artist/Album from freeDB, but no folder name & path, because some people have very strange way of naming their files.
All paths within EAC logs looks different for each guy, only the Artist/Album from freeDB in the first lines remains clean no matter the naming scheme. I am very happy with how it works right now, maths only no litteracy. Also if you add stuff like Folder: or Path: ... soon newbies will ask you to translate these & accurip logs will become less standardized.

I didn't mean the accurate rip log. I meant the main log i.e FolderName\... not present in database. Its very difficult to filter out the information in a glance...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-04-08 19:41:56
When trying to open CUEtools a second time while another encoding is already in progress, the second instance crashes without a useful message (like "you can only run it one time at once")...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: RolloTomasi on 2009-04-10 21:24:56
I've been messing around with 2.0.1 and I like it.  What I would like to see is a 'Correct Filenames' option that will write a new file, appending the original file name.  So if I have a folder full of FLAC files, I would keep the existing WAV cue intact.  This may have already been requested.  Sorry if that is the case.

I also noticed that the "Verify AR + CRC" option only works with EAC v0.99 logs.  It would be nice for it to work with 0.95 logs also.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: RolloTomasi on 2009-04-14 20:40:32
I also noticed that the "Verify AR + CRC" option only works with EAC v0.99 logs.  It would be nice for it to work with 0.95 logs also.

My mistake.  Verifying CRCs against the log file does not work in BATCH mode.  While in batch mode, it only REPORTS the CRCs.  Both versions of EAC appear to be supported.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2009-04-16 21:43:20
WOW, how did I miss this thread since I first tried AR in CT? Seems all my accuraterip-dreams has come true

I have a problem (with 2.0) though: I input track-separated flac-files and want to encode offset-corrected albums (still as track-separated) to a specified dir (using custom format). However, it seem not to recognize the artist and album as it creates this dir for everything:
"Unknown Artist - Unknown Title"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-16 22:51:58
I joined to ask what offset X, files accurately ripped means? Should my files be offset by 6 bits and then the will be accurately ripped? Is there an option to detect files as they are without offsetting them? Also can you add an option to generate a better formatted log for the folder so we can easily found out which folders are AR.

Your files are accurately ripped if they match at least one offset (pressing).
You might want to offset them by X samples before burning a CD-R, if you want an exact copy of an original CD.
If you burn with software which is not aware of drive offsets, you should offset your music by X + YourDriveWriteOffset.
What exactly would you call a better formatted log? Please, give an example.

Verifying CRCs against the log file does not work in BATCH mode.  While in batch mode, it only REPORTS the CRCs.

I'm still thinking if/how should the program be allowed to autolocate log files.
Currently in single mode when the program cannot find the .log file with same name as a .cue sheet, it asks a user to select a matching log file.
In batch mode it cannot ask a user. For now, try renaming your log files.

Thanks everyone for feedback, as usual i will try to fullfill most of the requests when i can.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-16 22:55:34
I have a problem (with 2.0) though: I input track-separated flac-files and want to encode offset-corrected albums (still as track-separated) to a specified dir (using custom format). However, it seem not to recognize the artist and album as it creates this dir for everything:
"Unknown Artist - Unknown Title"


Make sure "Fill up missing CUE data from tags" option is turned on.
Try also enabling 'Freedb lookup'.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-04-17 09:11:42
I'm still thinking if/how should the program be allowed to autolocate log files.
Currently in single mode when the program cannot find the .log file with same name as a .cue sheet, it asks a user to select a matching log file.
In batch mode it cannot ask a user. For now, try renaming your log files.

Hm, you could let it scan every file with the log extension for typical strings of EAC logs. That's how you can get the (list of all) log file(s) automatically without letting the user choose. This should work good enough for directories with only one .log file.

At the moment when there are more than one audio file and/or log files, CUE Tools prompts the user and he has to check the log by looking at it in the preview. While this works, too, it can be automated I think: CUETools should read all the CRCs of all the logs regardless, and compare them to the ones it will calculate later. That way at least a positive match can be confirmed, and the correct log can be linked to the correct audio file without the need of user interaction. Quite similar to how AR works actually. And if the CRCs do not match (for 2 CDs, there would be 4 CRCs, two from the logs and two calculated by CUETools), there can still be a prompt so that the user may choose which of the EAC logs is the correct one for each audio file.

In the end this should make the log selection prompt a much rarer sight.

Yet another trick would be to utilize the alphanumeric sort order of the log files, in case log and audio file basenames do not match. That should work in many cases for multi-CD albums at least. So the first audio file in the file list of the directory and the first log file probably are related to another, even if both logs come before both audio files or vice versa:

CDImage1.ape
CDImage2.ape
Unknown Title (CD1).log
Unknown Title (CD1).log

But this may fail, so it's not safe to to turn it on by default. Maybe it's a choice for batch processing if the user wants it to.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: RolloTomasi on 2009-04-20 15:49:20
Currently in single mode when the program cannot find the .log file with same name as a .cue sheet, it asks a user to select a matching log file.
In batch mode it cannot ask a user. For now, try renaming your log files.


In regards to the names matching, I figured that out since I posted.  For the most part, there will only be one log per folder, and using the EAC defaults, the log file name does NOT match the cue file name.  I suggest letting batch mode use the existing non-matching log if only one log exists, and skipping the log check if more than one exists.  Better than nothing.

Case in point.  I tested an album in batch mode, log file name did not match the cue file name.  The rip was individual tracks, gaps appended.  The Cue gave me an AR match, but the files did not.  Rather, they reported "Disk not present in database."  However, when I tested the same files in single mode, and selected the LOG file, an AR match was reported.  Any idea what would cause this discrepancy in results?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-20 15:56:14
Some CDs have nonstandard pregap (pause before the first track), some have data tracks.
If this information is missing, CUETools cannot calculate the correct disc id.
This information can be found in a .cue sheet or an EAC .log file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: RolloTomasi on 2009-04-20 16:44:32
The CD in question DOES have a non-standard [greater than 2 seconds] 1st track pregap.  Checking the same file with TripleFlac reports a match. 

But this DOES explain the discrepancy in results clearly.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-04-24 10:35:05
does cutools not support other languages (http://i23.photobucket.com/albums/b351/xcingix/misc/Untitled-1-3.jpg)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-04-24 11:13:04
What is this screenshot intended to prove?
However it works fine on my German system.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-04-24 12:03:29
that cutools couldn't give the files russian names.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-24 13:14:56
Turn off 'Remove special characters' option.
If you want it to support even more languages, turn off 'Force ANSI filenames' also.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mrinferno on 2009-04-24 16:05:09
awesome program, just wanted to pop into the thread and say thanks for all the hard work.
finally decided to download and try CUETools.  so far i've just been using it this morning to Verify AR + CRC's.  from the looks of it, plenty of potential other uses as well.
v2.0.1 x64 is working great for me on Vista Ultimate x64.

thanks again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-04-25 02:16:11
Turn off 'Remove special characters' option.
If you want it to support even more languages, turn off 'Force ANSI filenames' also.
thanks ill try it
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-04-26 23:03:37
im unhappy with the l8est unstable/experimental versions browsing behavior. cuetools is now using its own browser instead of windows' that is actually very slow for people with huge harddrives and a lot on them. my comp is pretty fast too. also i dont get an option to choose between my local .cue vs freedb and musicbrainz anymore.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-04-26 23:52:02
Use of cuetools' own browser is optional. You can still drag'n'drop files directly to the input box. In the next version it will be possible to hide the browser altogether. Also i'm pretty surprised that it's slow for you, because for me it works even faster than windows vista's explorer, and i have a 1TB+ archive.

Also it's strange that freedb doesn't work for you. Are you sure 'Freedb lookup' option in the main window is set to 'Always'? Or maybe you selected a folder as input, thus activating batch mode?

I realize that constant changes to the program are confusing, but i want this program to be more friendly to new users. I promise i'll make sure it doesn't loose any of it's features in this attempt to simplify the ui.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: joyus on 2009-04-27 23:29:11
Hi there, just want to say thanks for the tool. Decided to convert all my Flac + cue images into separate files +cue (Gaps Appended). All working fine, converting back to single wav image with cue seems to be going all well.

Have a small request for v2 with the new gui, it's not possible to view hidden folders in the file tree. Why would anyone need that?
Well i run cuetools through Parallels on the Mac. My drive is partition into 3 parts, one for each OS and a large storage drive where all the music is kept. Unfortunately on the MAC the file system lists additional partitions within a hidden /Volume/ and this is not accessible to CueTools v2, v 1.9.x works fine.
Now i can understand that viewing hidden folders might actually impact on the File Tree view of v2, but if it doesn't and if it is not time consuming to enable then it would be appreciated.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-01 04:16:34
I have a request: When I fix offset only if 100% tracks are confidence 2, Cuetools fix the offset according to the lowest offset difference. Would it be possible to have an option in order to have it match the offset with the highest confidence level instead of the closer one ... this doesn't matter for quality indeed but it is better IMHO than fixing to the closer offset. Why ? Because when there is an accuraterip purge then the rip with the closer offset might be deleted if it is not popular & then you end up having fixed your offset against a rip that is not in the database anymore ... targetting the offset with the highest overall accurate result for all tracks would avoid such un-wanted behavior. Thks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2009-05-01 15:57:09
Because when there is an accuraterip purge then the rip with the closer offset might be deleted if it is not popular

Are AccurateRip submissions really deleted just because they're not popular?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2009-05-01 16:01:32
No accurate rip records are deleted due to popularity.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-01 16:29:50
Check out the new build.

Have a small request for v2 with the new gui, it's not possible to view hidden folders in the file tree.

Forgot to do it in 2.0.2, i hope i won't forget it next time.

Would it be possible to have an option in order to have it match the offset with the highest confidence level instead of the closer one ...

Wierd request imho, but it was easy to add such an option, so i did it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-05-01 16:49:13
I just want to say thank you again for the latest version, Gregory! It's truly awesome.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-05-01 17:53:16
Aw, a new version without intermediate builds on SVN... gonna translate some new stuff, brb.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-01 18:42:54
Well as it seems nobody understund what I meant, maybe once again my english wasn't very good.

What I meant is that I like fixing the offset because it creates shorter logs (that has nothing to do with quality or safety), so before the recent virtual drive result purge I have fixed my offsets on my collection, just to get rid of some useless lines in my accuraterip logs but it happened that, due to the default system, I fixed my rips with offset/pressing that were close but with low confidence (say offset +1 confidence 2) instead of fixing my rips with a higher confidence but a bigger offset (say offset +1000 confidence 100). Now with the virtual drive purge the pressing with confidence 2 & offset +1  has disapeared ... so I have fixed my rips for nothing, if you have the option to match the offset with the higher confidence then you get rid of this annoyance ... or at least you highly reduce the probability. Not very usefull, but still nicer IMHO.

Thks for the new version I will try it right now
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-01 19:03:34
Aw, a new version without intermediate builds on SVN... gonna translate some new stuff, brb.

Sorry for that  I figured if i don't release a version today, i will start rewriting major parts again and there won't be new version for another month or so.

What I meant is that I like fixing the offset because it creates shorter logs...

Uncheck 'Verbose' option for log files, and you will have shorter logs
If you still want to 'fix' offsets, uncheck 'to nearest' option.
'Verify than encode' action is now replaced by "Encode and verify' with script 'fix offset' (you can select it in that combobox under available actions).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-05-01 19:10:36
Is it intended that the comboboxes are not translatable?

What about creating a new file for those strings (like the status bar messages, too) to allow translations?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-01 19:21:01
For status messages yes, but comboboxes mostly contain things that are unlikely to be translated - file extensions, encoder names...
Maybe it makes sense for script names, but most of those are very likely to be user-defined.
But you're right, i should make at least the word 'Default' translatable
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: user44 on 2009-05-02 09:04:11
'Verify than encode' action is now replaced by "Encode and verify' with script 'fix offset'.


When disc not present in database, 'Verify than encode' in old versions performs encoding without offset correction.
In new version 'Encode and verify' with script 'fix offset' does NOT perform encoding. Only displays 'Status Report: disk not present in database'.

Is it possible to modify the 'fix offset' script to perform encoding without offset correction, when disc not present in database?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-02 09:06:41
The new version seems to be going in the right direction. I already like V2.0.2 much more than 2.0.1 which I never really used.

I like the new parameters of the corrector, I like that "correct filenames" moved to "action", I like the new "drag the files here".

I will test it more & consider switching from 1.9.5a, it has several nice little features that I asked for so thks a lot.

As a sidenote the CUE icon is ugly when displayed as large icon. I don't care much but it's a shame that I change the icon on my desktop ... Even the same white & black icon but less pixelised when zoomed would do the job ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-02 16:39:36
Is it possible to modify the 'fix offset' script to perform encoding without offset correction, when disc not present in database?

Yeah.
In Advanced settings->Scripts, select any script and press insert.
Give it a name, e.g. 'fix anyway', check 'Verify and convert' in conditions, and copy-paste the script from 'fix offset'.
Modify the second line:

Code: [Select]
if (processor.ArVerify.AccResult != HttpStatusCode.OK)
    return processor.Go(); // was return processor.WriteReport();
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-05-02 17:32:13
As a sidenote the CUE icon is ugly when displayed as large icon. I don't care much but it's a shame that I change the icon on my desktop ... Even the same white & black icon but less pixelised when zoomed would do the job ...
We should start a logo contest. In a seperate thread, of course.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-05-03 08:45:57
Thanks for the improvements, I like 2.02 much more than 2.01.
The first  drag & drop into the directory tree is a bit slow, but after that it is quick as 1.9.5a
The correct filenames is a click more, but I can live with that 

I do have a request:
I would like a small status window where, after a task, the status report is showed in stead of the pop-up window.
Or maybe it could be showed in the bar on the same place where it shows how far a verify is.
I don't like pop-up windows which I must close before I can proceed.

Maybe this isn't possible because of the length of some status messages.
In that case:

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-03 10:21:56
typo: action verify: displayed tip ==> databse instead of database

also when I select lossy: ogg just below I have the choice between oggenc & nero aac & when I select m4a nero aac is not there, I didn't try these options but I guess there is a problem there too.

The logic would be :
m4a: nero aac
ogg: oggenc

& not :
m4a: empty
ogg: oggenc & nero aac

I didn't tried but having nero aac under ogg was surprising ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-03 11:21:09
When using a short version of log would it be possible that valid result from incomplete pressing/offset would be excluded

Actually if the rip in the database is

offset xxx
1 100/100
2 100/100
3 00/100
4 00/100

offset yyy
1 00/100
2 00/100
3 100/100
4 100/100

the short log will ouput this:
All offset
1 100/100
2 100/100
3 100/100
4 100/100

the user of the short log version will not be aware that there might be a problem with offset.

the short log should only display valid results if there are valid results with at least confidence 1 for all track within the same offset ... doing so most valid rips will not be affected. (at worst they should display a little less results) while incomplete pressings will not be reported as perfect ...

with this filter my exemple would return:
All offset
1 0/100
2 0/100
3 0/100
4 0/100

which would warn you to do a long log to understand what is happening.

Also would it be possible to have an option to output the short log in front of the long log & also an option to output both long & short long at the same time separately ... because actually if I want both I fear will have to run my collection twice which I don't like ...

Finally I already asked for it but I redo as it is important for me: would it be possible to have an option to hide "as in pressing(s) #" within the logs because these numbers means nothing (specially when tangled) & are disturbing. It's nothing but added noise in my log, I dislike seeing it, each time I read my logs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2009-05-03 11:26:18
As a sidenote the CUE icon is ugly when displayed as large icon. I don't care much but it's a shame that I change the icon on my desktop ... Even the same white & black icon but less pixelised when zoomed would do the job ...
We should start a logo contest. In a seperate thread, of course.

Exactly six months ago, I created an icon set for cuetools. I did it for personal use, but my intention was to perhaps give it some finishing touches and offer it to Gregory as a very modest contribution from my side. At some stage, before I had a chance to revisit the design, Gregory added the current icon and I didn't feel that my contribution was necessary anymore.

However, I have happily used my icon set with my shortcuts and I think it works quite well. Here is how it looks:

(http://i224.photobucket.com/albums/dd212/AB2K/ha/cuetools.png)

(http://i224.photobucket.com/albums/dd212/AB2K/ha/cuetools_properties.png)

The gearwheel is an attempt to visualize the word "tools" and the sun-like ball kind of symbolizes the recreation power of CUETools. The functional purpose of its shape and colors is naturally to make it easily distinguishable in all sizes.

I attached a ready to use .ico file (in a zip package). It contains the icon in four common standard sizes. Feel free to use it if you like the design.

[attachment=5077:cuetools_icon_set.zip]

Gregory, as I said, I think I could give the design some finishing touches and also further develop it so that it would be usable as a logo.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-03 11:40:23
Well that's all about taste ... personnaly I don't like gearwheel much, my problem with the old icon is not that I don't like it, but that it doesn't seem to include a large version of the icon, so as I use large icon it use a zoomed small icon which create ugly pixelisation ... also black & white is a little sad ... the old icon with your sun in the back would be perfect for my need. Another option would be to create a sunny like gearwheel & remove the word CUE from the icon as 99% of icons don't include text.

In the end it's up to Gregory to decide so I don't care much ... give me a non-pixelised large icon that's all I ask
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-05-03 15:31:59
I do have a request:
I would like a small status window where, after a task, the status report is showed in stead of the pop-up window.
Or maybe it could be showed in the bar on the same place where it shows how far a verify is.
I don't like pop-up windows which I must close before I can proceed.

ImgBurn uses an extra window for that. It can be stickied to the main window. I think that's a very elegant solution, since you can close the status window if you don't want to see it, of course.


Gregory, as I said, I think I could give the design some finishing touches and also further develop it so that it would be usable as a logo.
Well, I like it. It's definetly better than the current one.  Finishing touches would include making it "Vista-ready", i.e. bigger bitmaps. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-05-03 19:51:54
Quote
ImgBurn uses an extra window for that. It can be stickied to the main window. I think that's a very elegant solution, since you can close the status window if you don't want to see it, of course.


Is also a fine solution. As long as I can proceed without a mandatory click.
Autowrap and a choice between status report or log would be nice in that case.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-04 04:38:23
Cosmetic request:

Actually results are sorted by offset no matter if the results are good or bad, could the results still be sorted by offset but grouping good results with good results in front & bad results with bad results in the bottom.

For exemple actually we have:

Code: [Select]
[Verification date: 03/05/2009 19:42:46]
[Disc ID: 000cdb40-00609af6-7209a309]
Pregap length 00:00:32.
Track    [ CRC    ] Status
01    [dd66af1f] (10/25) Accurately ripped as in pressing(s) #1
02    [0913cf12] (10/26) Accurately ripped as in pressing(s) #1
03    [0baae567] (10/26) Accurately ripped as in pressing(s) #1
04    [fa0725ba] (10/25) Accurately ripped as in pressing(s) #1
05    [e566df1c] (10/25) Accurately ripped as in pressing(s) #1
06    [fa882817] (10/25) Accurately ripped as in pressing(s) #1
07    [e8e6d151] (10/26) Accurately ripped as in pressing(s) #1
08    [a6e967a7] (10/25) Accurately ripped as in pressing(s) #1
09    [247fd59b] (10/24) Accurately ripped as in pressing(s) #1
Offsetted by 51:
01    [ed0a694b] (02/25) Accurately ripped as in pressing(s) #4
02    [b719e5c3] (02/26) Accurately ripped as in pressing(s) #4
03    [2bbf587c] (02/26) Accurately ripped as in pressing(s) #4
04    [6d8a58a6] (02/25) Accurately ripped as in pressing(s) #4
05    [ccaea6c2] (02/25) Accurately ripped as in pressing(s) #4
06    [88d92bee] (02/25) Accurately ripped as in pressing(s) #4
07    [16282b32] (02/26) Accurately ripped as in pressing(s) #4
08    [3c250b8d] (02/25) Accurately ripped as in pressing(s) #4
09    [d5575d93] (02/24) Partial match to pressing(s) #4
Offsetted by 657:
01    [a6e01c83] (09/25) Accurately ripped as in pressing(s) #2
02    [d465c546] (09/26) Accurately ripped as in pressing(s) #2
03    [d34c7529] (09/26) Accurately ripped as in pressing(s) #2
04    [1ddd62f2] (09/25) Accurately ripped as in pressing(s) #2
05    [0130ef32] (09/25) Accurately ripped as in pressing(s) #2
06    [05c8ff34] (09/25) Accurately ripped as in pressing(s) #2
07    [11c7481c] (09/26) Accurately ripped as in pressing(s) #2
08    [de16e349] (09/25) Accurately ripped as in pressing(s) #2
09    [19b2bc43] (09/24) Accurately ripped as in pressing(s) #2
Offsetted by 930:
01    [fa97d3e7] (04/25) Accurately ripped as in pressing(s) #3
02    [bf2b1dd9] (05/26) Accurately ripped as in pressing(s) #3
03    [e69fb170] (05/26) Accurately ripped as in pressing(s) #3
04    [58a8fb39] (04/25) Accurately ripped as in pressing(s) #3
05    [0ad7e311] (04/25) Accurately ripped as in pressing(s) #3
06    [59f322d1] (04/25) Accurately ripped as in pressing(s) #3
07    [5e615667] (05/26) Accurately ripped as in pressing(s) #3
08    [dece9beb] (04/25) Accurately ripped as in pressing(s) #3
09    [9f2566eb] (03/24) Partial match to pressing(s) #3

Track    [ CRC32  ]    [W/O NULL]    
--    [8EABAAA6]    [35EAF7A9]    
01    [AAF365AA]    [D8B6D46B]    
02    [A5FB5392]    [95F59865]    
03    [B3239AE3]    [AD32FF39]    
04    [40BB5312]    [1682867B]    
05    [C6E4854D]    [BC1DEFAC]    
06    [3C96C5B8]    [08C20719]    
07    [B224471B]    [ACBA60BF]    
08    [7424A68B]    [26A14BA7]    
09    [6AB8C336]    [20C653C5]


with some sorting we could have:

Quote
[Verification date: 03/05/2009 19:42:46]
[Disc ID: 000cdb40-00609af6-7209a309]
Pregap length 00:00:32.

Good Results:
Track   [ CRC   ] Status
01   [dd66af1f] (10/25) Accurately ripped as in pressing(s) #1
02   [0913cf12] (10/26) Accurately ripped as in pressing(s) #1
03   [0baae567] (10/26) Accurately ripped as in pressing(s) #1
04   [fa0725ba] (10/25) Accurately ripped as in pressing(s) #1
05   [e566df1c] (10/25) Accurately ripped as in pressing(s) #1
06   [fa882817] (10/25) Accurately ripped as in pressing(s) #1
07   [e8e6d151] (10/26) Accurately ripped as in pressing(s) #1
08   [a6e967a7] (10/25) Accurately ripped as in pressing(s) #1
09   [247fd59b] (10/24) Accurately ripped as in pressing(s) #1
Offsetted by 657:
01   [a6e01c83] (09/25) Accurately ripped as in pressing(s) #2
02   [d465c546] (09/26) Accurately ripped as in pressing(s) #2
03   [d34c7529] (09/26) Accurately ripped as in pressing(s) #2
04   [1ddd62f2] (09/25) Accurately ripped as in pressing(s) #2
05   [0130ef32] (09/25) Accurately ripped as in pressing(s) #2
06   [05c8ff34] (09/25) Accurately ripped as in pressing(s) #2
07   [11c7481c] (09/26) Accurately ripped as in pressing(s) #2
08   [de16e349] (09/25) Accurately ripped as in pressing(s) #2
09   [19b2bc43] (09/24) Accurately ripped as in pressing(s) #2

Bad results:
Offsetted by 51:
01   [ed0a694b] (02/25) Accurately ripped as in pressing(s) #4
02   [b719e5c3] (02/26) Accurately ripped as in pressing(s) #4
03   [2bbf587c] (02/26) Accurately ripped as in pressing(s) #4
04   [6d8a58a6] (02/25) Accurately ripped as in pressing(s) #4
05   [ccaea6c2] (02/25) Accurately ripped as in pressing(s) #4
06   [88d92bee] (02/25) Accurately ripped as in pressing(s) #4
07   [16282b32] (02/26) Accurately ripped as in pressing(s) #4
08   [3c250b8d] (02/25) Accurately ripped as in pressing(s) #4
09   [d5575d93] (02/24) Partial match to pressing(s) #4
Offsetted by 930:
01   [fa97d3e7] (04/25) Accurately ripped as in pressing(s) #3
02   [bf2b1dd9] (05/26) Accurately ripped as in pressing(s) #3
03   [e69fb170] (05/26) Accurately ripped as in pressing(s) #3
04   [58a8fb39] (04/25) Accurately ripped as in pressing(s) #3
05   [0ad7e311] (04/25) Accurately ripped as in pressing(s) #3
06   [59f322d1] (04/25) Accurately ripped as in pressing(s) #3
07   [5e615667] (05/26) Accurately ripped as in pressing(s) #3
08   [dece9beb] (04/25) Accurately ripped as in pressing(s) #3
09   [9f2566eb] (03/24) Partial match to pressing(s) #3

Track   [ CRC32  ]   [W/O NULL]   
--   [8EABAAA6]   [35EAF7A9]   
01   [AAF365AA]   [D8B6D46B]   
02   [A5FB5392]   [95F59865]   
03   [B3239AE3]   [AD32FF39]   
04   [40BB5312]   [1682867B]   
05   [C6E4854D]   [BC1DEFAC]   
06   [3C96C5B8]   [08C20719]   
07   [B224471B]   [ACBA60BF]   
08   [7424A68B]   [26A14BA7]   
09   [6AB8C336]   [20C653C5]


the more results there are the more it make the log easier to read, & if there are more then 10 results you are sure that the good results are displayed first, while actually it displays the ten first results no matter if it's noise.

As a sidenote I use .acc.txt as my extension personnaly, it's searchable & supported by default by winxp, short & instantly identifiable. I think you could put the cuetools version that generated the log within the log because if you don't know cuetools you may ask yourself where the text file come from & what does it means ... actually you have no clue specially if the extension is not default.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-04 07:34:50
A behavior that I don't understand:

If I use "append to finename"+New:

CDImage.cue
CDImage.flac
CDImage.log

I want it to output

CDImageNew.cue
CDImageNew.flac
CDImageNew.log

It tells me that files already exist, ask if I want to overwrite & the report tells me that source folder cannot be the same as output folder ... so I am forced to use "create a subdirectory"+New & then move my files which is slow & is a pain if you have a big collection. I don't understand because with New appended to filename, the path is not exactly the same anymore ... so it shouldn't try to overwrite CDImage.flac but just write a new CDImageNew.flac file in the same directory ? No ?

Is this working correctly, am I just thinking that "append to finename"+New is supposed to behave in a way that it is not intended to behave ?

If I only want to verify I can use "in source folder", I want the same thing (with a different filename indeed) when I write cue+flac+log, what option am I supposed to use ?

As a sidenote, CUETools V2.0.2 is nice, it has so many new features/fixes that I wanted that I have completely get rid of V1.9.5a now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: goaman15 on 2009-05-06 01:47:38
Great tool!

Is there a way to write a CUE sheet for WAV files?

Example write:

FILE "01-whatever.wav" WAVE

Instead of

FILE "01-whatever.flac" WAVE

Even though the files are FLAC?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-06 13:03:48
the user of the short log version will not be aware that there might be a problem with offset.

Not quite.
In fact, the output will be like

1 100/100 with offset(s) xxx
2 100/100 with offset(s) xxx
3 100/100 with offset(s) yyy
4 100/100 with offset(s) yyy

This contains all the important information about the rip accuracy.
So in my opinion, the short log is totally enough if you don't care about pressing numbers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-06 14:41:30
The short log version doesn't display any info about offset if the offset is correct (which is normal) & unfortunately I only tested on albums with fixed offset so I wasn't seeing this information ... that's why I thought it would behave like this. Short logs seems more interesting now that I know offset are included, thks. My mistake, sorry.

Quote
[Verification date: 06/05/2009 15:35:28]
[Disc ID: 00097de0-0032a15c-5f094606]
Track    Status
01    (39/39) Accurately ripped with offset(s) 102
02    (39/39) Accurately ripped with offset(s) 102
03    (39/39) Accurately ripped with offset(s) 102
04    (39/39) Accurately ripped with offset(s) 102
05    (39/39) Accurately ripped with offset(s) 102
06    (39/39) Accurately ripped with offset(s) 102

Track   [ CRC32  ]   [W/O NULL]   [  LOG  ]
--   [AEEEF003]   [7F3E4567]    W/O NULL
01   [27B9F38A]   [0AD58D4D]   
02   [6E00EE2D]   [82FFFE8A]   
03   [B4BFD657]   [923B9A8A]   
04   [3B488384]   [A8A2EC20]   
05   [D4B897B3]   [20E88B93]   
06   [0355B0CE]   [823FD78A]   

01   [A9CA3FE6]   [BB8EF499]   
02   [75724575]   [F57105B8]   
03   [961C45E7]   [1DD2490E]   
04   [393435E8]   [A4E86A92]   
05   [46BC57DA]   [1B2F7913]   
06   [DF276EAF]   [D736A794]   
07   [B4FC6610]   [A85BEF3E]   
08   [BFF40CD3]   [98683549]   
09   [E3EBDE40]   [02A681CF]   
10   [65C27299]   [523716EE]   
11   [B584BC23]   [7E69281B]


Code: [Select]
[Verification date: 06/05/2009 15:34:26]
[Disc ID: 00097de0-0032a15c-5f094606]
Track    [ CRC    ] Status
01    [9c413287] (00/39) No matches
02    [2e7863a3] (00/39) No matches
03    [5a8e2933] (00/39) No matches
04    [b40d87ca] (00/39) No matches
05    [f801ac04] (00/39) No matches
06    [ac3716b6] (00/39) No matches
Offsetted by 102:
01    [ba22a97f] (39/39) Accurately ripped as in pressing(s) #1
02    [cd97987b] (39/39) Accurately ripped as in pressing(s) #1
03    [7745e99d] (39/39) Accurately ripped as in pressing(s) #1
04    [320444b2] (39/39) Accurately ripped as in pressing(s) #1
05    [59153532] (39/39) Accurately ripped as in pressing(s) #1
06    [c0875030] (39/39) Accurately ripped as in pressing(s) #1

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
--    [AEEEF003]    [7F3E4567]     W/O NULL
01    [27B9F38A]    [0AD58D4D]    
02    [6E00EE2D]    [82FFFE8A]    
03    [B4BFD657]    [923B9A8A]    
04    [3B488384]    [A8A2EC20]    
05    [D4B897B3]    [20E88B93]    
06    [0355B0CE]    [823FD78A]


Below with offset already fixed, there is no info on offset displayed ... quite normal, but it misslead me at first as I am used to long logs with lot of offsets ...

Code: [Select]
[Verification date: 06/05/2009 15:29:34]
[Disc ID: 0013d426-00ad3f96-9c0b460b]
Track     Status
01     (02/06) Accurately ripped
02     (02/06) Accurately ripped
03     (02/06) Accurately ripped
04     (02/06) Accurately ripped
05     (02/06) Accurately ripped
06     (02/06) Accurately ripped
07     (02/06) Accurately ripped
08     (02/06) Accurately ripped
09     (02/06) Accurately ripped
10     (02/06) Accurately ripped
11     (02/06) Accurately ripped

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
--    [70B05B5B]    [E22286CB]     W/O NULL
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-06 14:53:49
Is this working correctly, am I just thinking that "append to finename"+New is supposed to behave in a way that it is not intended to behave ?

I tested this, and found out that "append to finename" works ok with single file images, but doesn't work in gaps appended mode, because track filenames don't get this suffix. I will have to think what to do about it. Does it work for you with single file images?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-06 16:08:22
Well I dunno what more to say that I haven't already said, I don't know how it is supposed to work in your mind so I don't know if it's normal ... all I know is that I thought it would output CDImageNEW.flac in the same folder as the CDImage.flac input, but it doesn't, it wants to overwrite as if "NEW" wasn't appended to filename. It is not a new behavior, it has always worked like that even in pre-acuraterip cuetools version I think as I have always used create a subfolder "NEW" instead as it wasn't working for me, so it might very well be normal, but in case it is normal I don't understand what it is supposed to do, because it doesn't work as I understand it... the short awnser is no it doesnt work with CDImage for me. As far as I can recall it never did & I used cuetools since a long time now. It never annoyed me much because so far I only pass a few albums at the same time though cuetool, but now that I intend to pass my whole collection though accuraterip it is more annoying. It is MUCH easier to output CDIMageNEW in the same folder & then batch delete all files without NEW appended, than to switch between folders to cut/past/delete & replace old files from sourcefolder with new files from NEW subfolder.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-06 16:15:53
I see.

For single image rips this works if Advanced Settings->CUETools->Single format is set to %F. (forcing the flac filename to be equal to the cue sheet filename, so that it also gets that -new suffix).
Probably also works ok for file-per-track rips if track format includes %F, like %N. %F - %T.
I will see how to make it work in other situations.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-06 16:24:33
Well I just verified this setting, it seems %F is set by default, I think I never changed it & it never worked here ...

Edit: Maybe there should be a parameter before "NEW" in the "append to filename" box ? Maybe I have deleted something there ?

Note: I am running WinXP SP2 not Vista. In a couple of months when I will install Win7 RC I will see if it change anything ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-08 11:47:37
I didn't tell it because it was obvious for me but indeed, if you try to convert one format to another it works because the path is not the same, for example I can convert wavpack to flac:

Input:
CDImage.wv
CDImage.cue
CDImage.log

it will output:
CDImage.flac
CDImageNEW.cue
CDImageNEW.log

but even in this case you can notice that "NEW" is appended to .cue & .log but NOT to the audio file, which is why it doesn't work when converting flac to flac.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-08 14:16:08
For single image rips this works if Advanced Settings->CUETools->Single format is set to %F. (forcing the flac filename to be equal to the cue sheet filename, so that it also gets that -new suffix).
Probably also works ok for file-per-track rips if track format includes %F, like %N. %F - %T.
I will see how to make it work in other situations.

Correction: "Keep original filenames" must be turned off for this to work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-08 19:28:16
Thks a lot, it works like a charm now. I knew I was doing something bad, it couldn't be a non-fixed bug for so long, it had to be me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2009-05-09 06:11:44
I love this tool!

One simple addition would be fantastic. When verifying and/or fixing offsets and writing the new results to a new folder, would it be possible to copy all the other files from the source folder (scans, etc.)? And even optionally completely delete the source folder upon successful verification?

This would make it trivial to batch a huge collection and not have to manually check what passed verification and what didn't. I am currently copying all my old rips from data CD-Rs and DVD-Rs to an external hard drive and it would be great to verify them in one pass and have the verified & fixed offset versions moved to a different folder called "GOOD" along with the scans and whatever other ancillary files I have in the source folder. Ideally when the batch is done, everything verified would be in the "GOOD" folder and everything remaining in the source folder would need a closer manual inspection.

Perhaps this can already be done with scripting. My only concern is that I would probably wipe out my hard drive and set the garage on fire. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2009-05-11 01:33:36
Hi Gregory,

I have a small request for you, regarding to "Verify" using the "write AR tags" option.

According to the tooltip for this option, it only writes the ACCURATERIPCOUNT, ACCURATERIPCOUNTALLOFFSETS and ACCURATERIPTOTAL tags.

All my albums are single file FLAC+CUE (i.e.: 1 file per album). Having said that, it seems correct that none of the above AR tags get written, since they seem to target individual tracks.

Since I'm dealing with whole albums, I wonder why the ACCURATERIPID tag isn't written as well ? It would be a really helpful addition when trying to identify how many albums are not in the AR DB (by doing a query in foobar). So for example, everytime the AR DB gets updated I could just verify only those albums (the ones missing the ARID tag) to see if they were included, and if so, the AR tag will get written, so in the end i'll have fewer albums to verify on the following iterations of this process.

I hope I made myself clear.

Thanks for all the hard work !

N.



Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-05-11 11:35:57
In the next version it will be possible to hide the browser altogether.
I promise i'll make sure it doesn't loose any of it's features in this attempt to simplify the ui.

good to know. im looking forward to it
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-13 01:35:21
I have a new request  would it be possible to have a verify mode that would only verify if the Disc ID is present or not in the database without checking any CRC if present & only output the usual log, when disk is not present:

Code: [Select]
[Verification date: 03/05/2009 20:39:31]
[Disc ID: 000c38f1-005434a4-610a4608]
Disk not present in database.


This would allows to do a very fast 1st pass on my collection when CPU is already working, & start sorting my rips by moving all Disc ID not present in database to a new folder. Then I could do the 2nd pass & fix all offset for rips present in the database when my CPU is free. Purging all disks not in database would also help me to evaluate the real encoding time needed to fix all my offsets to the highest accuraterip count pressing. I think it must be easy to add such a mode to the actual verify mode, I dunno call it something like "Check for Disk not present in database without calculating CRC" or something shorter with this as a tip balloon pop up ... Also it would allow fast re-checking of rips previously not in database that might have been added.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-13 02:26:12
This sort of things is done using scripts. There is a sample script called "only if found" which stops verification when disc is not found in the database. You can either use it (by selecting it in the combobox under the actions list), or you can create your own script for something more alaborate. I'm hoping users will start posting their scripts here someday, so we can set up some kind of script database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-13 02:36:06
I know about "only if found" my idea comes from this script, but I don't know about scripting langage. Anyway I think that this idea is usefull for everyone because everyone will have rips not in database & will sooner or later wants to re-check them. Let's hope that someone who find the idea usefull will script it. The problem with "only if found" is that it does calculate CRC if it found the disk ID which is slow, I want a blazing fast mode just to check if Disk ID is present. I have tryed to cheat "only if found" to behave in a way that would suit my needs but it didn't work as if it's in the database it calculates CRC no matter if I put it on "encode if verified" 100% tracks confidence 999 or strange settings like this. I don't want it to start calculating CRC at all, I just want to know if it's in database or not.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-16 03:52:23
I just installed windows seven RC, I just wanted to let you know that the displaying bug when using medium font 120PP(125%) is still here:

(http://img31.imageshack.us/img31/6436/clipboard01.png)

... it is a very minor bug, windows seven is very very good, even for a die-hard anti-vista like me, the good thing with win7 is that you can switch font settings without rebooting, so this bug is much less annoying than previously, I just wanted to let you know that it was still there in win7 so I think all windows versions are affected. Cuetools is the only software I use that produce bug at 125% ... at 150% many programs have problems, but not at 125%. Also it seems to produce another displaying bug that I cannot reproduce right now, when I use 125% clic on advanced setting then clic on ok sometimes cuetool goes back to 100% within the 125 % windows. It's not very annoying too, but the bug exists. Closing Cuetools & relaunching it fix the bad display. Anyway I prefer that you add new features than that you waste your time with this. But still I wanted you to be aware of it.

PS: I run a Socket A Semprom 3000 (2Ghz) with 1Go of DDR-400 on an nforce 2 mobo (very old PC), IMHO win7 is clearly faster than both xp (a few, due to integrated missing XP features) & vista (by far), the RC is far more stable than Vista final, I recommend it to everyone. (I couldn't really use Vista with my slow PC, I can use win7 flawlessly)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-05-17 13:42:23
A bit late reply but thank you for the new version! I like the UI alot.
Also thank you for the cuesheet generator update. Now I can create cuesheets for my embedded flac in a matter of seconds! (some progs still need external ones)

Working flawlessly with 2.02 x64 version under Windows7 x64 btw.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2009-05-17 14:57:27
I have a question... (Edit: make that three)

Some years ago I ripped my CD's into flac/cue, but at some point I switched to separate tracks. I've converted all my images into single-tracks using foobar2000. I suppose foobar2000 leave out the pregap before track1, right?

1. Would I be able to better determine accuraterip accuracy (+offset) if I have the original cue-sheet? (possible missing pregap from track1)

2. Can I verify my separate track files using a cuesheet that were made along with the image at first?

3. Can I verify an album of separate tracks with a non-compliant cuesheet that specifies filenames that doesn't match those in the same folder?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-17 15:00:35
Here is a screenshot of the 2nd (even less annoying than the first) displaying bug at 125%.

(http://img196.imageshack.us/img196/6039/clipboard01k.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 2009-05-17 17:33:09
1. Would I be able to better determine accuraterip accuracy (+offset) if I have the original cue-sheet? (possible missing pregap from track1)

2. Can I verify my separate track files using a cuesheet that were made along with the image at first?

3. Can I verify an album of separate tracks with a non-compliant cuesheet that specifies filenames that doesn't match those in the same folder?

To answer all three questions, CUE Tools can create a CUE sheet for your separate tracks. Use that CUE sheet to determine AccurateRip accuracy.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-17 22:14:59
1. Would I be able to better determine accuraterip accuracy (+offset) if I have the original cue-sheet? (possible missing pregap from track1)

No. Only if you split the image back to separate files, to use with that original cue sheet.

2. Can I verify my separate track files using a cuesheet that were made along with the image at first?

Not, unless you merge them to an image. And even then, not if there was a pregap.

3. Can I verify an album of separate tracks with a non-compliant cuesheet that specifies filenames that doesn't match those in the same folder?

Yes.

To conclude: use the cue sheet that matches the number of actual files. Use non-compilant cue sheet for separate tracks, and single file cue sheet for image.
If you lost a pregap information in that cue sheet, in most cases CUETools will be able to find it in a .log file, using either "TOC of the extracted CD" or "Pre-gap length  0:00:02...";
When batch processing, .log file will only be used if it matches .cue sheet filename; e.g. image.log for image.cue;
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2009-05-17 23:07:30
1. Would I be able to better determine accuraterip accuracy (+offset) if I have the original cue-sheet? (possible missing pregap from track1)

No. Only if you split the image back to separate files, to use with that original cue sheet.

They were image at first, but now they are separate files.

2. Can I verify my separate track files using a cuesheet that were made along with the image at first?

Not, unless you merge them to an image. And even then, not if there was a pregap.

If there once was a pregap that has been cut off while converting them to separate files, combining them again wouldn't that result in showing as if there's a huge offset?

To conclude: use the cue sheet that matches the number of actual files. Use non-compilant cue sheet for separate tracks, and single file cue sheet for image.
If you lost a pregap information in that cue sheet, in most cases CUETools will be able to find it in a .log file, using either "TOC of the extracted CD" or "Pre-gap length  0:00:02...";
When batch processing, .log file will only be used if it matches .cue sheet filename; e.g. image.log for image.cue;

Basically I want to AR-verify all my albums and store the integrity in tags, but I never really kept logs and cues. I'm just asking to know if I'm wasting my time trying to rip the cuesheet off all my CD's again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-05-17 23:41:19
Pregap affects discid, so you just won't find a disc in database if pregap was non-zero and you lost it. It cannot show as an offset.
Yes, you can re-rip the non-compliant cue-sheet and use it with those separate files, and pregap will be found in that cue sheet.
But you can also just use EAC to detect the pregap length, enter it in CUETools window and verify separate files without any cue sheet.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-18 15:39:43
I have created a very basic icon following the original design, it brings nothing new as I didn't wanted the reinvent the wheel but it fixes the pixelisation when using large icon, the original icon seems to be upscaled 16x16 when viewed as large icon. My icon include 16x16, 24x24, 32x32 & 48x48 all generated from the 48x48 PNG.

(http://img35.imageshack.us/img35/8991/cuetools.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-05-18 15:45:14
But you can also just use EAC to detect the pregap length, enter it in CUETools window and verify separate files without any cue sheet.

In most cases the pregap (if not 0) is 32,33 or 37. If I want to check files without cue-sheet, I check with those 4 values, it's faster then to find the cd and determine pregap.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-05-20 22:18:46
Watching at the accuraterip logo:
(http://img200.imageshack.us/img200/3528/accuraterip.png)
I had the idea to replace the U with a check mark, I know the check mark is closer to V, but it's only an idea I throw.
It give something like this:
(http://img35.imageshack.us/img35/4656/cuetools248x4816m.png)
... stylized & with the original accuraterip CD color in the background it might be nice, but this is beyond my very limited skill... (Maybe a simple CD thumbnail in the background would do the job too, I didn't try yet)

PS: The check mark I used is not the original one, I used one from Check Marks (http://commons.wikimedia.org/wiki/Category:Logic_icons)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-05-21 08:34:16
Just a small annoyance: version 1.9.5a takes as log-name the directory-name. Version 2.02 takes the name of the first track as log-name.
I would prefer the directory-name or (if available) the Artistname - Albumtitel from cue or log.

Maybe this is already possible, but I can't find the right setting then 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: 3NoGa on 2009-05-28 13:57:47
I want to say a few words about the main window, which displays information about the process.

This is not quite comfortable when you need to move a scroll bar left and right, to find and read the message, "rip accurate, rip is not accurate", especially when checked at once a large number of albums, and (depending on the number of characters in the title of the album, and the length of the path to it) the inscription "rip accurate, rip not accurate" is not one above another that making it difficult to track.

Accordingly, it would be nice to do something like this:
xxxx ........| rip accurate
yyyy ........| rip not accurate
zzzz ........| rip accurate....

...and so on, so that the messages "accurate rip, rip is not accurate" to appear in one column, one above the other.

The path and name of the disc can be shown in abbreviated form, as if pointing the mouse to display the full path and full name of the album.
I think it would be more convenient to read.

For the message "rip not accurate" best use of color, or put it in bold, that in the results column, it was immediately clear that there are albums with the unsatisfactory results of the verification.

In addition, (once CueTools able to check the archives), it would be very helpful if the final results show DISCID for each album.
This option would be simply irreplaceable and would save a lot of time when you sort all kinds of material (eg, downloaded from eMule).

For example, the results would appear as:
AAAA ........| rip accurate ...................| DISCID 1
BBBB ........| rip not accurate ...........| DISCID 1
CCCC ........| rip accurate ...................| DISCID
DDDD ........| rip accurate ...................| DISCID
EEEE ........| rip accurate ...................| DISCID 2
FFFF .........| rip accurate ...................| DISCID 2
GGGG ........| rip not accurate ...........| DISCID 2

and so on - with an additional column, which appears DISCID value for each disc.

For labeling of albums with the same DISCID can use numbers (as shown above) or use some other way.

   
Good to be able to save a report in the form of .LOG, which would indicate albums with identical DISCID.
Ideally - a report in Excel, where in addition to the above data could also see accurip separate reports for each disk.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-05-30 00:15:27
its not great but im using this as the icon
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2009-05-31 20:36:40
I have a problem verifying some releases. As I understand it, it should automatically pick up the log-file from the same dir and determine pregap from it. Well it doesn't seem to pick up the log and neigher it seem to work when I write in the pregap manually - Still it's not detected in the AR database, although the rip-log says Accurately Ripped.

Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 10. August 2008, 14:32

Pet Shop Boys / Discography - The Complete Singles Collection

Used drive  : LITE-ON DVDRW LH-20A1S  Adapter: 5  ID: 0

Read mode : Burst

Read offset correction   : 6
Overread into Lead-In and Lead-Out   : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations   : No
Used interface   : Native Win32 interface for Win NT & 2000
Gap handling : Not detected, thus appended to previous track

Used output format   : User Defined Encoder
Selected bitrate : 768 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : D:\Programmer\Exact Audio Copy\FLAC\FLAC.EXE
Additional command line options : -8 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=%e" %s -o %d


TOC of the extracted CD

Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  |  0:00.33 |  4:00.07 | 33 | 18039 
2  |  4:00.40 |  4:18.45 | 18040 | 37434 
3  |  8:19.10 |  3:38.00 | 37435 | 53784 
4  | 11:57.10 |  4:04.23 | 53785 | 72107 
5  | 16:01.33 |  5:01.22 | 72108 | 94704 
6  | 21:02.55 |  4:20.10 | 94705 |  114214 
7  | 25:22.65 |  3:33.20 | 114215 |  130209 
8  | 28:56.10 |  3:54.68 | 130210 |  147827 
9  | 32:51.03 |  4:17.42 | 147828 |  167144 
  10  | 37:08.45 |  4:18.25 | 167145 |  186519 
  11  | 41:26.70 |  4:47.73 | 186520 |  208117 
  12  | 46:14.68 |  4:20.10 | 208118 |  227627 
  13  | 50:35.03 |  4:00.57 | 227628 |  245684 
  14  | 54:35.60 |  4:51.23 | 245685 |  267532 
  15  | 59:27.08 |  4:32.25 | 267533 |  287957 
  16  | 63:59.33 |  4:15.15 | 287958 |  307097 
  17  | 68:14.48 |  4:14.32 | 307098 |  326179 
  18  | 72:29.05 |  4:23.23 | 326180 |  345927 


Track  1

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\01. Pet Shop Boys - West End Girls.wav

Timing problem 0:00:00
Timing problem 0:00:17

Peak level 100.0 %
Copy CRC B692546B
Accurately ripped (confidence 9)  [5DEF00CE]
Copy finished

Track  2

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\02. Pet Shop Boys - Love Comes Quickly.wav

Timing problem 0:00:12

Peak level 100.0 %
Copy CRC F0A00795
Accurately ripped (confidence 8)  [3BFE5B6C]
Copy finished

Track  3

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\03. Pet Shop Boys - Opportunities (Let's Make Lots Of Money).wav

Timing problem 0:03:14
Timing problem 0:03:34

Peak level 98.7 %
Copy CRC 1DFF220B
Accurately ripped (confidence 8)  [31569190]
Copy finished

Track  4

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\04. Pet Shop Boys - Suburbia.wav

Timing problem 0:01:37
Timing problem 0:02:01

Peak level 100.0 %
Copy CRC 25AC4B10
Accurately ripped (confidence 8)  [A5992150]
Copy finished

Track  5

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\05. Pet Shop Boys - It's A Sin.wav

Timing problem 0:01:57
Timing problem 0:02:06
Timing problem 0:02:42

Peak level 100.0 %
Copy CRC 2AF6EBE8
Accurately ripped (confidence 8)  [F485B75B]
Copy finished

Track  6

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\06. Pet Shop Boys - What Have I Done To Deserve This .wav

Peak level 98.3 %
Copy CRC 06A77818
Accurately ripped (confidence 8)  [520D6AAC]
Copy OK

Track  7

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\07. Pet Shop Boys - Rent.wav

Peak level 97.2 %
Copy CRC 931B0A6A
Accurately ripped (confidence 8)  [C7931D86]
Copy OK

Track  8

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\08. Pet Shop Boys - Always On My Mind.wav

Peak level 96.3 %
Copy CRC 297375FF
Accurately ripped (confidence 8)  [0607935A]
Copy OK

Track  9

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\09. Pet Shop Boys - Heart.wav

Peak level 97.7 %
Copy CRC DC48378C
Accurately ripped (confidence 7)  [F7821F0D]
Copy OK

Track 10

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\10. Pet Shop Boys - Domino Dancing.wav

Peak level 96.5 %
Copy CRC CD234230
Accurately ripped (confidence 8)  [8EF78F39]
Copy OK

Track 11

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\11. Pet Shop Boys - Left To My Own Devices.wav

Peak level 98.5 %
Copy CRC EAD1D4C0
Accurately ripped (confidence 8)  [210267F3]
Copy OK

Track 12

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\12. Pet Shop Boys - It's Alright.wav

Peak level 100.0 %
Copy CRC FD182052
Accurately ripped (confidence 8)  [61318ADE]
Copy OK

Track 13

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\13. Pet Shop Boys - So Hard.wav

Peak level 100.0 %
Copy CRC 8D1CD243
Accurately ripped (confidence 8)  [FC786BBC]
Copy OK

Track 14

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\14. Pet Shop Boys - Being Boring.wav

Peak level 95.6 %
Copy CRC F02751A7
Accurately ripped (confidence 7)  [325811B1]
Copy OK

Track 15

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\15. Pet Shop Boys - Where The Streets Have No Name (I Can't Take My Eyes Off You).wav

Peak level 100.0 %
Copy CRC 95CEF937
Accurately ripped (confidence 7)  [65D1EA20]
Copy OK

Track 16

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\16. Pet Shop Boys - Jealousy.wav

Peak level 95.7 %
Copy CRC 67B0BDFB
Accurately ripped (confidence 8)  [D8718C91]
Copy OK

Track 17

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\17. Pet Shop Boys - DJ Culture.wav

Peak level 100.0 %
Copy CRC E46426E0
Accurately ripped (confidence 7)  [B6395AB2]
Copy OK

Track 18

Filename M:\Ripped\Pet Shop Boys - Discography - The Complete Singles Collection\18. Pet Shop Boys - Was It Worth It .wav

Peak level 100.0 %
Copy CRC 34923054
Accurately ripped (confidence 8)  [92EF8F59]
Copy OK


All tracks accurately ripped

No errors occurred

End of status report
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-06-02 13:45:59
Is there a chance that CUETools could verify images of cds with multimedia sections? As it says something like
Quote
CD-Extra data track length 01:20:26 - 01:21:25.
Disk not present in database.
and stops verification now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-02 13:56:11
I have a problem verifying some releases. As I understand it, it should automatically pick up the log-file from the same dir and determine pregap from it. Well it doesn't seem to pick up the log and neigher it seem to work when I write in the pregap manually - Still it's not detected in the AR database, although the rip-log says Accurately Ripped.

In batch mode it will pick up the log only if it's filename is exactly the same as cue sheet's (xyz.cue -> xyz.log). Log seems fine, so no idea what's wrong.

Is there a chance that CUETools could verify images of cds with multimedia sections? As it says something like
Quote
CD-Extra data track length 01:20:26 - 01:21:25.
Disk not present in database.
and stops verification now.

Option 1) Make sure there's a log from a fresh EAC version available, so that CUETools can find out CD-Extra data track length from log.
Option 2) Find "AppData->Roaming->CUE Tools->settings.txt" file, open it in notepad and add "BruteForceDTL=1" line.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-06-02 14:30:23
Option 2) Find "AppData->Roaming->CUE Tools->settings.txt" file, open it in notepad and add "BruteForceDTL=1" line.
Thanks for the hint!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2009-06-02 15:04:47
I have a problem verifying some releases. As I understand it, it should automatically pick up the log-file from the same dir and determine pregap from it. Well it doesn't seem to pick up the log and neigher it seem to work when I write in the pregap manually - Still it's not detected in the AR database, although the rip-log says Accurately Ripped.

In batch mode it will pick up the log only if it's filename is exactly the same as cue sheet's (xyz.cue -> xyz.log). Log seems fine, so no idea what's wrong.

But I don't have a cue-sheet, just a set of ripped files.

Actually I wonder, why some albums verify accurately with a very high confidence number, many with just 1 og 2 in confidence and a lot not at all (assuming the missing pregap). I wonder because I thought that redbook standard needs at least 0:02 sec pregap.

In theory, could pre-gap not be detected just as offset can?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-06-02 16:21:46
No pregap for the first track in a cue means it is 2 seconds.

Pregaps cannot be detected like offsets, not even in theory.  Have a look at the part of the code used to generate Disc IDs combined with the way AR lookup works and you'll understand.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-06-02 18:46:37
Quote
Actually I wonder, why some albums verify accurately with a very high confidence number, many with just 1 og 2 in confidence and a lot not at all (assuming the missing pregap). I wonder because I thought that redbook standard needs at least 0:02 sec pregap.


It is possible to find a match at a pregap 0 with confidence 1 or 2 and a match with pregap 32 (or 33,37) with a much higher confidence.
In such a case the low confidence match with 0 pregap is probably (IMHO) from a cdr rip.
If I'm not certain of the source I always check 0,32,33,37 pregap. Those are the most common pregaps.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tijgert on 2009-06-04 17:12:52
I'm new to Cuetools but I'm really quite amazed at this versatile little tool.

But is there a way to also cut the music images into their seperate songs?
(when converting, you can see it's processing each track... it should be easy to just cut it at the end and start the next track).

Me personally I'd like to convert my single file Ape image to seperate Flac tracks.
I could use three or four tools consecutively to do that, but I'd rather use just a single one... this one...

It's especially handy since some of my Ape files have no identification or cue files at all and with this tool I could get fully named Flac files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-04 17:24:49
Did you try setting "CUE Style" to "Gaps Appended"?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Jayrcee on 2009-06-05 18:11:45
Love the program, but I just started getting an error when trying to convert an album from APE to FLAC.  It is "Exception: Object reference not set to an instant of an object."  It happens after I have selected my log file and it is looking up the album from freedb then MusicBrainz.  Any help would be appreciated!  Thanks!  (happens in 1.9.5 and 2.0.2)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-05 18:29:52
Does it only happen with this album, is there something specific about it or it happens with all albums, or with all your albums in APE? Can you please try to research the problem a bit?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Jayrcee on 2009-06-05 21:58:07
It doesn't happen with every album I use CueTools with, and it's not happening just with APE files.  It has done it with WavPack and WAV.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2009-06-14 20:35:11
I'd like to propose following 2 additions to this wonderful tool:

1) drop-down list with user's custom naming schemes (for example, I use %0\cdimage.cue for single image and %C (flac) for tracks and I have to type them each time I swith from one mode to another);

2) a naming scheme for verify log (I'd sometimes use %C.accurip and sometimes accuraterip.log).

What does Gregory S. Chudov think about it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-15 08:54:52
Makes sense. We'll see if i have time for this when i'll start preparing next version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pimaga on 2009-06-16 09:56:07
Hi,

First, thank you very much for this very useful tool !
I would like to know if there is some manual page somewhere, because the readme file is kind of bare :-)
In particular, I would like to know how to use the /fix parameter of the command line. For me, it opens CUETools but do nothing more...

Thanks again,

Pimaga
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pimaga on 2009-06-16 10:09:49
OK, in fact, it works fine in 1.9.5a. It's a bug of the instable version.
Anyway, some additional details about how to use the command line would be helpful.
For example, which settings are used when I use the /fix flag ? Is it possible to specify other settings as additional parameters ?

Thanks a lot !



Hi,

First, thank you very much for this very useful tool !
I would like to know if there is some manual page somewhere, because the readme file is kind of bare :-)
In particular, I would like to know how to use the /fix parameter of the command line. For me, it opens CUETools but do nothing more...

Thanks again,

Pimaga

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Boiled Beans on 2009-06-16 10:17:24
When fixing offset values, after it verifies with Accurate Rip, is it possible to choose which offset to apply?

Right now, I have to "Verify AR" on the first run, remember the confidence level for the pressing I want, then adjust the Accurate Rip "with confidence" in the Advanced Settings to choose which offset to apply, then run "Verify, then encode".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-06-16 11:27:24
Right now, I have to "Verify AR" on the first run, remember the confidence level for the pressing I want, then adjust the Accurate Rip "with confidence" in the Advanced Settings to choose which offset to apply, then run "Verify, then encode".


You should choose encode and verify and then choose fix offset from the pull down menu. It will fix the offset to the one which is closest to your rip.
This way the least samples are discarded.
Choosing the fix the offset to the pressing with the highest confidence level makes imho no sense at all. You're just discarding more samples then necessary.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pimaga on 2009-06-16 14:38:16
OK, I continue to reply to myself :-)
I understand that when CUETools is invoked from the command line, the settings contained in the settings.txt file are applied, and I assume that they can't be modified by additional parameters.

In fact, I would like to split some CDImage.ape by some CDImage.cue with applying simultaneously an offset correction (not depending on accurip, but set manually according to the drive model appearing in the log file).
This works using the GUI, but with the /convert command, the split is done without the offset correction. Is it a bug or a feature ? Is there something to change in the settings.txt ?

Thank you in advance.

OK, in fact, it works fine in 1.9.5a. It's a bug of the instable version.
Anyway, some additional details about how to use the command line would be helpful.
For example, which settings are used when I use the /fix flag ? Is it possible to specify other settings as additional parameters ?

Thanks a lot !



Hi,

First, thank you very much for this very useful tool !
I would like to know if there is some manual page somewhere, because the readme file is kind of bare :-)
In particular, I would like to know how to use the /fix parameter of the command line. For me, it opens CUETools but do nothing more...

Thanks again,

Pimaga


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2009-06-16 23:30:41
I still can't manage to make it work as expected.

I ripped a CD with a pregap of 00:08:00 and a data track of 00:08:00, with Confidence 3 in EAC to separate tracks and created a cue-file with current settings. Verifying in CUETools to write AR tags, but it doesn't recognize it, even when it asks for the log-file. Neigher can I make it recognize it when I enter the values manually.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-18 18:44:33
I still can't manage to make it work as expected.

I ripped a CD with a pregap of 00:08:00 and a data track of 00:08:00, with Confidence 3 in EAC to separate tracks and created a cue-file with current settings. Verifying in CUETools to write AR tags, but it doesn't recognize it, even when it asks for the log-file. Neigher can I make it recognize it when I enter the values manually.

I tried to verify this using dummy files with same lengths as in a log that you sent me. There were no problems:

Code: [Select]
[Verification date: 18.06.2009 21:31:09]
[Disc ID: 002a53cf-01dc7ff5-ec12aa10]
Pregap length 00:08:00.
CD-Extra data track length 00:08:00.
Track Status
 01 (00/03) No matches
 02 (00/03) No matches
 03 (00/03) No matches
 04 (00/03) No matches
 05 (00/03) No matches
 06 (00/03) No matches
 07 (00/03) No matches
 08 (00/03) No matches
 09 (00/03) No matches
 10 (00/03) No matches
 11 (00/03) No matches
 12 (00/03) No matches
 13 (00/03) No matches
 14 (00/03) No matches
 15 (00/03) No matches

Track [ CRC32  ] [W/O NULL] [  LOG  ]
 -- [420F3D4E] [00000000] W/O NULL
 01 [A1985E48] [00000000] [68B186E3]
 02 [EE896089] [00000000] [88E98B88]
 03 [57954675] [00000000] [AACB27CD]
 04 [070B9517] [00000000] [F515831E]
 05 [B7E0B086] [00000000] [7A5E2521]
 06 [7CED5E61] [00000000] [E8D30054]
 07 [1E83BC5D] [00000000] [9657E354]
 08 [E13DDE0D] [00000000] [234B0B5E]
 09 [B8003064] [00000000] [7188AB89]
 10 [257CA442] [00000000] [0A9E261D]
 11 [EE309B70] [00000000] [28A5C491]
 12 [75A0DDB5] [00000000] [159B3C57]
 13 [FF89AFE7] [00000000] [1383FD33]
 14 [EF48FB28] [00000000] [109FBFB4]
 15 [B2F6DF81] [00000000] [969C92FE]

Can you please compare your files length with the log? Foobar2000 can show you the file's length in samples. The length from log is calculated like this: (End sector + 1 - Start sector) * 588.
e.g. the first track should have length (34486+1-600)*588==19925556 samples.

My current hypothesis is that EAC made some tracks shorter, when it failed to rip them.

I will add a check for that in the next version i guess.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Boiled Beans on 2009-06-18 18:51:34
Right now, I have to "Verify AR" on the first run, remember the confidence level for the pressing I want, then adjust the Accurate Rip "with confidence" in the Advanced Settings to choose which offset to apply, then run "Verify, then encode".


You should choose encode and verify and then choose fix offset from the pull down menu. It will fix the offset to the one which is closest to your rip.
This way the least samples are discarded.
Choosing the fix the offset to the pressing with the highest confidence level makes imho no sense at all. You're just discarding more samples then necessary.


I just tried doing that, but all that happens is that it encodes and shows the Accurate Rip pressing info. No Fix offset option. I'm using 1.9.5 btw. Is this a feature in the newer 2.0.2 version?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-18 19:05:06
OK, I continue to reply to myself :-)
I understand that when CUETools is invoked from the command line, the settings contained in the settings.txt file are applied, and I assume that they can't be modified by additional parameters.

In fact, I would like to split some CDImage.ape by some CDImage.cue with applying simultaneously an offset correction (not depending on accurip, but set manually according to the drive model appearing in the log file).
This works using the GUI, but with the /convert command, the split is done without the offset correction. Is it a bug or a feature ? Is there something to change in the settings.txt ?

Thank you in advance.


Command line support is very limited currently. Additional parameters, such as /offset, might appear in the future.

I personally am not very fond of the whole idea of offset correction, because to me this seems like a totally useless operation,
which doesn't make a rip better. It only makes it worse by cutting some samples from the beginning or the end.
We only needed it in the past to be able to use AccurateRip, but now we can do it without offset correction.
I will continue to support offset correction in CUETools, because there are probably a lot of people with different views,
but i'm not making it a priority.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-18 19:14:03
I just tried doing that, but all that happens is that it encodes and shows the Accurate Rip pressing info. No Fix offset option. I'm using 1.9.5 btw. Is this a feature in the newer 2.0.2 version?

Yep, that's how it works in 2.0.2. There's an option 'to nearest' in AccurateRip Fix offset settings. If it's turned on, the closest offset is chosen. If it's turned off, the most popular offset is chosen. You can also write a custom script which selects an offset for you.

Although my opinion on the whole offset correction thing is in the above message.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-06-21 08:36:34
I personally am not very fond of the whole idea of offset correction, because to me this seems like a totally useless operation,
which doesn't make a rip better. It only makes it worse by cutting some samples from the beginning or the end.


I only use offset correction in case of a repair: I sometimes combine two sources to make 1 accurate album. In such cases I use it to get all files on the same offset.
I know it's not making it sounding better, but it's just looks better in the log 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pimaga on 2009-06-21 08:42:07
Thanks a lot for your reply, I can understand your position (even if it is reassuring, for us neurotic geeks, to know that we have the exact same tracks as on the original CD).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-06-22 18:40:56
Obviously CUETools fail at decoding .ape files. Just tried to encode a CUE'd APE file to .ogg. Got broken files with a cracking noise instead.
eD2K link to the particular file, if needed, by PM...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2009-06-23 01:17:34
Obviously CUETools fail at decoding .ape files. Just tried to encode a CUE'd APE file to .ogg. Got broken files with a cracking noise instead.
eD2K link to the particular file, if needed, by PM...


There's nothing obvious about you statement. CUETools converted my 1500+ .ape (v3.97) files to .flac without problems.

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-06-23 01:36:44
Well, in this particular case it is obvious to me. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-06-23 11:17:39
Well, in this particular case it is obvious to me. 


Why is it obvious that it is the ape decoding ? The problem can also lie in de ogg encoding.
I also converted several ape/cue images to flac files. Didn't encounter any problems (yet)
But maybe I need to listen more closely.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-23 11:26:12
It works forks for me.

If you use 'Encode and verify mode', what does the final log say?
If it says something like this:
--   [DB0F2EE1]   [8EA1A6C5]     CRC32
i.e. CRCs match the log file, then the problem is not with ape decoder,
but with external ogg encoder. Can you try a different encoder?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-06-23 22:32:46
Ok, I just recently found CUETools and it's great! I have tested the prog (version 2.0.2a) and I read the whole thread last weekend, BUT I still got tons of questions/suggestions/etc., I thought about your sanity Gregory and I will not post all of them in one post (some of the problems/questions include logs, who have guessed).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-24 20:15:18
Is it necessary to "lock" all .log files (even non-existant ones(?)) in the directory when starting/running ArCueDotNet.exe?

The file at this moment exists and is locked by windows because of the output redirection.
CUETools doesn't lock the file. It only tries to open it, because it might be a EAC log file, which CUETools uses.
The point is, CUETools shouldn't abort on such error. I''ll probably fix it in the next version.

HDCD: peak extend: none, transient filter: none, gain: none

This is most probably a false alert. This happenes sometimes, when
a random audio data looks like HDCD encoding by coincidence.
A real HDCD would have at least one of the three features turned on.

Thanks for other reports/suggestions as well, i will look into this someday
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-24 20:17:52
CUETools 2.0.3 is out.

I was pretty busy lately, so this release is not very different from the previous,
most of the stuff that i promissed to fix will be fixed only in 2.0.4.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-06-24 20:31:24
Some strings are missing in SVN. Like "Check for updates". 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-24 20:41:06
Just commited them. Should be there by now.

Sorry, i messed up many strings this time. Again
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-06-24 20:43:54
I see. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-06-24 20:52:41
Some are still missing, like "Drag the files here".   
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-24 20:55:54
Uh oh 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-25 00:38:10
I wrote a brief manual on new output path template syntax: http://www.cuetools.net/doku.php/cuetools:template (http://www.cuetools.net/doku.php/cuetools:template)
Those are wiki pages, so anyone can contribute. Feel free to join the CUETools documentation project.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Boiled Beans on 2009-06-25 08:10:42
This is most probably a false alert. This happenes sometimes, when
a random audio data looks like HDCD encoding by coincidence.
A real HDCD would have at least one of the three features turned on.

Thanks for other reports/suggestions as well, i will look into this someday


I do have some HDCDs which behave similarly though.

E.g. The Bee Gees - Their Greatest Hits The Record. They are listed as HDCD on the back cover and on the CD itself, but when I run the file through Sox or CUETools, HDCD encoding is detected but all the variables say "none".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: denisk1981 on 2009-06-25 08:53:50
Hi!

Can U pls handle the resolution issue. It's really annoying:

(http://img230.imageshack.us/img230/773/cuetools.jpg)


THNX!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-25 10:20:32
Large fonts?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-25 11:20:30
E.g. The Bee Gees - Their Greatest Hits The Record. They are listed as HDCD on the back cover and on the CD itself, but when I run the file through Sox or CUETools, HDCD encoding is detected but all the variables say "none".

If you uncheck 'Settings->HDCD->Stop looking after 750 frames', more data will be analyzed. On the downside, this leads to more false alerts.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: denisk1981 on 2009-06-25 12:02:36
Large fonts?



I think it's anchoring of the controls in the right panel...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-06-25 14:13:00
Thanks for the previous answers. Here's the 2nd part of my questions/etc.

I'd like to verify something, if I get a log like below (if possible at all), is my rip really accurate? (log is a mock-up) I.e. it doesn't matter what offsets the verifications come from as long as all tracks are accurately ripped? Does it only mean that TRACKS were accurately ripped? Not that my PRESSING of the album was accurately ripped? Have I understood correctly that AR DB doesn't care about pressings? Or can I only be confident when all tracks WITHIN one offset are accurately ripped?

Code: [Select]
Track	[ CRC    ] Status
 01 [xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #2
 02 [xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #2
 03 [xxxxxxxx] (00/03) No matches
 04 [xxxxxxxx] (00/03) No matches
 05 [xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #2
Offsetted by 12:
 01 [xxxxxxxx] (00/03) No matches
 02 [xxxxxxxx] (00/03) No matches
 03 [xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #1
 04 [xxxxxxxx] (00/03) No matches
 05 [xxxxxxxx] (00/03) No matches
Offsetted by 280:
 01 [xxxxxxxx] (00/03) No matches
 02 [xxxxxxxx] (00/03) No matches
 03 [xxxxxxxx] (00/03) No matches
 04 [xxxxxxxx] (03/03) Accurately ripped as in pressing(s) #3
 05 [xxxxxxxx] (00/03) No matches

I'd like to +100 to the following suggestions:

1) Remove the pressing numbers from the logs! Those just confuse people.

2) Make a "summary" of the verified tracks.. IF there's an accurately ripped matches for ALL tracks WITHIN one offset, write something like: "Disc accurately ripped."? Otherwise, I don't know, can one say that it was NOT 100% accurately ripped? Suggestions?

3) I like the 2 suggestions in this post: http://www.hydrogenaudio.org/forums/index....st&p=631889 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=631889)
   3.1) Include the version of CUETools in the log.
   3.2) Quoting sauvage78: "grouping good results with good results in front & bad results with bad results in the bottom" would be really nice.. especially dividing the results with distinct "Good Results:" and "Bad results:" headers! Would be more easier to understand (and perhaps accept) the results..?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-06-25 15:02:26
Quick new additional question:

Is it possible to use the "only if found" script with "CUETools.exe [/verify] "filename"" or with "ArCueDotNet.exe"? If not, please consider adding it.

EDIT:

The "hide browser" is very nice but there's one small annoyance; if one stretches the window horizontally to see the browser more nicely and then clicks the hide button and browser button again, the previous stretched horizontal window size is not remembered.

P.S. The "where is their vote?" is nice but consider adding a link to somewhere explaining it. Also you might like to think again about getting political with your software, it's your choice of course and I do like it very much, but e.g. check this forum (http://sourceforge.net/forum/forum.php?forum_id=813349) the owner of Notepad++ had to set up because the anger messages of Notepad++ "Boycott Beijing 2008" "advert" started to fill the normal forums.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: denisk1981 on 2009-06-25 18:31:31
Hi, Gregory.

Is the source project available. I'm interested in GUI only.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Boiled Beans on 2009-06-26 05:54:41
Thanks for the previous answers. Here's the 2nd part of my questions/etc.

I'd like to verify something, if I get a log like below (if possible at all), is my rip really accurate? (log is a mock-up) I.e. it doesn't matter what offsets the verifications come from as long as all tracks are accurately ripped? Does it only mean that TRACKS were accurately ripped? Not that my PRESSING of the album was accurately ripped? Have I understood correctly that AR DB doesn't care about pressings? Or can I only be confident when all tracks WITHIN one offset are accurately ripped?

I'd like to +100 to the following suggestions:

1) Remove the pressing numbers from the logs! Those just confuse people.

2) Make a "summary" of the verified tracks.. IF there's an accurately ripped matches for ALL tracks WITHIN one offset, write something like: "Disc accurately ripped."? Otherwise, I don't know, can one say that it was NOT 100% accurately ripped? Suggestions?

3) I like the 2 suggestions in this post: http://www.hydrogenaudio.org/forums/index....st&p=631889 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=631889)
   3.1) Include the version of CUETools in the log.
   3.2) Quoting sauvage78: "grouping good results with good results in front & bad results with bad results in the bottom" would be really nice.. especially dividing the results with distinct "Good Results:" and "Bad results:" headers! Would be more easier to understand (and perhaps accept) the results..?

I did experience something like this in a few of my CDs, where the pressings are different.

Code: [Select]
Track	[ CRC    ] Status
 01 [xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #2
 02 [xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #2
 03 [xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #1
 04 [xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #1
 05 [xxxxxxxx] (03/04) Accurately ripped as in pressing(s) #2

Offsetted by 12:
 01 [xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #1
 02 [xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #1
 03 [xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #2
 04 [xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #2
 05 [xxxxxxxx] (01/04) Accurately ripped as in pressing(s) #1

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-26 09:22:20
I'd like to verify something, if I get a log like below (if possible at all), is my rip really accurate?

A log like this is almost impossible.
Yes, AccurateRip collects data on per-track basis.
Different tracks might verify against different offsets,
if there was a certain number inserted/deleted in between.
I saw such cases, but it results in some track inbetween
(where this insertion/deletion took place) reported as inaccurate.

1) Remove the pressing numbers from the logs! Those just confuse people.
...

I strongly recomment to turn off the 'Verbose' log file option. The log would be much more simple.
The full log with 'pressings' etc is not very helpfull except for people who are really interested in
what's going on inside the database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-26 09:29:36
Is it possible to use the "only if found" script with "CUETools.exe [/verify] "filename"" or with "ArCueDotNet.exe"? If not, please consider adding it.

I will.

The "hide browser" is very nice but there's one small annoyance; if one stretches the window horizontally to see the browser more nicely and then clicks the hide button and browser button again, the previous stretched horizontal window size is not remembered.

Will be fixed in the next version.

P.S. The "where is their vote?" is nice but consider adding a link to somewhere explaining it. Also you might like to think again about getting political with your software, it's your choice of course and I do like it very much, but e.g. check this forum (http://sourceforge.net/forum/forum.php?forum_id=813349) the owner of Notepad++ had to set up because the anger messages of Notepad++ "Boycott Beijing 2008" "advert" started to fill the normal forums.

People who don't know what this is about can google it out in one second, if they are curious enough. Don't want to waste more pixels with a link
As for those who might not like it, there's a simple solution - turn off the check for updates and delete motd.jpg from AppData\Roaming\CUETools folder.
This place in the UI will be normally used for update notification banner.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-06-26 09:36:40
Hi, Gregory.

Is the source project available. I'm interested in GUI only.


There is link to source code repository at the top of this thread.
It's http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/ (http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/)

By the way, i think i fixed the problem with GUI for nonstandard fonts.
Try this one please: [attachment=5200:CUETools...0.3a_x86.rar]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: denisk1981 on 2009-06-27 11:43:49
Hi, Gregory.

Is the source project available. I'm interested in GUI only.


There is link to source code repository at the top of this thread.
It's http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/ (http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/)

By the way, i think i fixed the problem with GUI for nonstandard fonts.
Try this one please: [attachment=5200:CUETools...0.3a_x86.rar]



THNX. It's perfect now!!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-06-27 12:34:35
Thanks again for the answers, though you missed this one: "Or can I only be confident [that my pressing of the CD is ok] when all tracks WITHIN one offset are accurately ripped?"

I strongly recomment to turn off the 'Verbose' log file option. The log would be much more simple. The full log with 'pressings' etc is not very helpfull except for people who are really interested in what's going on inside the database.

Well at the moment I don't want to use the non-verbose log because IMHO there's a big problem with it, which I'll demonstrate in my next post. I'm sorry but what purpose does the "as in pressing(s) #x" information serve? Is it in any way usable? IMHO, and as some others have said, it's just confusing people, it doesn't serve a purpose. And, IF I've understood correctly, the offsets represents pressings already, then why distract the user from that by outputting these non-relevant "as in pressing(s) #x" texts? Of course it's your decision but please consider making the log more understandable.

Don't want to waste more pixels with a link ... This place in the UI will be normally used for update notification banner.

I meant that can't you put a link to that image, not a separate text link.. does the update banner have a link to download site?

P.S. Clicking the text links in the about dialog does absolutely nothing in my PC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-06-27 12:59:30
Compare the 2 logs.

1) Why is the "Accurately ripped with offset(s) 0(2)" in the non-verbose log? I thought that "Partial match to pressing(s)" meant that track is NOT accurately ripped.

1.1) Is the "Partial match" really necessary? Especially if that really means that the rip was NOT good at all.

2) Why is there two "280(2)" listed?

3) Why is there one "1690(2)" and one "1690(0)" listed?

4) If it's true that "if all tracks within one offset are accurately ripped, the DISC is accurately ripped", then shouldn't the non-verbose log show only the confidence numbers from "whole offset(s) fully accurately ripped"? (example below)

 01    (07/09) Accurately ripped with offset(s) 12(5),1690(2)
 02    (07/09) Accurately ripped with offset(s) 12(5),1690(2)
 ...

IMHO the current non-verbose output, simply put, lies about the accurate statuses e.g. in this case. Or if not lies, then at least it represents the situation very difficultly.. in the end the "09/09" for that 1st track is NOT "correct".. that's the easiest figure/result to understand, IMHO the offsets stuff is too hard to decipher to normal users. The AR stuff is hard enough to understand already, please try to make it more easier to understand. Thanks.

Code: [Select]
[Disc ID: 001165eb-009914a6-9b0b400b]
Track [ CRC    ] Status
 01 [733a3c74] (02/09) [color=#FF0000]Partial match to pressing(s) #2[/color]
 02 [647133aa] (02/09) Accurately ripped as in pressing(s) #2
 03 [5ea8c8cb] (02/09) Accurately ripped as in pressing(s) #2
 04 [200fe976] (02/09) Accurately ripped as in pressing(s) #2
 05 [7fcc75a0] (02/09) Accurately ripped as in pressing(s) #2
 06 [174b2628] (02/09) Accurately ripped as in pressing(s) #2
 07 [a61e417e] (02/09) Accurately ripped as in pressing(s) #2
 08 [89e54391] (02/09) Accurately ripped as in pressing(s) #2
 09 [125ec64e] (02/09) Accurately ripped as in pressing(s) #2
 10 [cde305a7] (02/09) Accurately ripped as in pressing(s) #2
 11 [cd3692ce] (02/09) Accurately ripped as in pressing(s) #2
Offsetted by 12:
 01 [f810eac3] (05/09) Accurately ripped as in pressing(s) #1
 02 [674e80df] (05/09) Accurately ripped as in pressing(s) #1
 03 [8b0e7c4e] (05/09) Accurately ripped as in pressing(s) #1
 04 [f6c64064] (05/09) Accurately ripped as in pressing(s) #1
 05 [3107a254] (05/09) Accurately ripped as in pressing(s) #1
 06 [c528d657] (05/09) Accurately ripped as in pressing(s) #1
 07 [62383801] (05/09) Accurately ripped as in pressing(s) #1
 08 [3ca8f35d] (05/09) Accurately ripped as in pressing(s) #1
 09 [a220407f] (05/09) Accurately ripped as in pressing(s) #1
 10 [812c1092] (05/09) Accurately ripped as in pressing(s) #1
 11 [e042a7c7] (05/09) Accurately ripped as in pressing(s) #1
Offsetted by 280:
 01 [51d2c1b1] (02/09) Accurately ripped as in pressing(s) #2
 02 [4b880d8d] (00/09) No matches
 03 [1aed0e9e] (00/09) No matches
 04 [0c6900e4] (00/09) No matches
 05 [47478718] (00/09) No matches
 06 [4f1b6237] (00/09) No matches
 07 [b5c87777] (00/09) No matches
 08 [77c22e05] (00/09) No matches
 09 [c1a449cd] (00/09) No matches
 10 [26001712] (00/09) No matches
 11 [0607bd12] (00/09) No matches
Offsetted by 1690:
 01 [0cdfc996] (02/09) Accurately ripped as in pressing(s) #3
 02 [3c459d7e] (02/09) Accurately ripped as in pressing(s) #3
 03 [f8e0ac37] (02/09) Accurately ripped as in pressing(s) #3
 04 [687a061c] (02/09) Accurately ripped as in pressing(s) #3
 05 [502eee2f] (02/09) Accurately ripped as in pressing(s) #3
 06 [f5164085] (02/09) Accurately ripped as in pressing(s) #3
 07 [a1400942] (02/09) Accurately ripped as in pressing(s) #3
 08 [3abf62fe] (02/09) Accurately ripped as in pressing(s) #3
 09 [5fd526a3] (02/09) Accurately ripped as in pressing(s) #3
 10 [3b920429] (02/09) Accurately ripped as in pressing(s) #3
 11 [7f674c04] (02/09) Accurately ripped as in pressing(s) #3

Code: [Select]
[Disc ID: 001165eb-009914a6-9b0b400b]
Track Status
 01 (09/09) Accurately ripped with offset(s) [color=#FF0000]0(2)[/color],12(5),[color=#FF0000]280(2),280(2)[/color],[color=#FF0000]1690(2),1690(0)[/color]
 02 (09/09) Accurately ripped
 03 (09/09) Accurately ripped
 04 (09/09) Accurately ripped
 05 (09/09) Accurately ripped
 06 (09/09) Accurately ripped
 07 (09/09) Accurately ripped
 08 (09/09) Accurately ripped
 09 (09/09) Accurately ripped
 10 (09/09) Accurately ripped
 11 (09/09) Accurately ripped

This is the last part of my questions/etc.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NachoMan77 on 2009-06-27 14:16:46
Hi Gregory,

I'm testing 2.0.3a.

Two issues so far:

1) the new compression level control doesn't remember the last setting used. This is a step back for me, as I always encode FLACs at 8, en everytime I restart the CUETools it starts with the default 5 compression level.

2) Can you add the option in Audio output formatting "Use CUE formatting template" ?  Since I deal with single FLACs & CUEs, both with the same name, whenever I need to switch the CUE template, I need to manually change the Audio formatting config.

3) Not an issue really, but what about my previous request for writing the ACCURATERIPID tag for Single File + CUE ?

Thanks,

N.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-06-27 15:28:53
I'm sorry but what purpose does the "as in pressing(s) #x" information serve? Is it in any way usable?

Even Spoon agrees that this information is useless.  It should be removed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-06-27 20:15:43
Tried Cuetools 2.0.3.a in drag 'n dropmode.
While verifying it shows if an album is accurately ripped just as in 2.02. After finishing it shows in the batch log but in that just the directories which were dropped.
It shows the status report after switching to drag'n drop mode (or (multiselect) file browser) and then to batch log again.

Also the switching to batch-log is imho no improvement to the status report in separate window. Instead of a close button, the drag'n drop icon must be clicked before continuing.
I would very much like a separate window or area in which the status report is shown which doesn't intervene with dragging and dropping.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-06-27 21:57:05
Tried Cuetools 2.0.3.a in drag 'n dropmode.
While verifying it shows if an album is accurately ripped just as in 2.02. After finishing it shows in the batch log but in that just the directories which were dropped.
It shows the status report after switching to drag'n drop mode (or (multiselect) file browser) and then to batch log again.


I forgot to mention this happens with dragging more than 1 directory
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-06-29 15:30:34
I still use v2.02a because of the display bug with 125% font which has get worst in 2.03

(http://img209.imageshack.us/img209/3303/clipboard01prr.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2009-06-29 20:09:26
I still use v2.02a because of the display bug with 125% font which has get worst in 2.03


Are you talking about version from [a href='index.php?act=findpost&pid=643682']this[/a] post?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-06-29 21:11:46
No, I was speaking of the one in the download front page. Thks for the fixed version I missed it. I didn't test it much so far, but the display seems to work ok now. It's a good news that it is finally fixed as it has been annoying me for months now.

V2.03 with Fixed Display: (on Windows 7 RC1)

(http://img199.imageshack.us/img199/3946/clipboard01mmg.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2009-06-30 16:21:59
Can you please compare your files length with the log? Foobar2000 can show you the file's length in samples. The length from log is calculated like this: (End sector + 1 - Start sector) * 588.
e.g. the first track should have length (34486+1-600)*588==19925556 samples.

My current hypothesis is that EAC made some tracks shorter, when it failed to rip them.

All tracks had the correct length, but I think the data-track is the culprit here - I don't have an audio-file the the data-track. I tried entering 0:08:00 in the "Data track" inputbox, but still fails.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-06-30 17:34:18
I just post to say that the bug with 125% fonts is only partially fixed, in fact the part that was fixed is the buggy main windows introduced in v2.03, the buggy advanced settings/accuraterip windows from 2.02a remains buggy:

Still buggy advanced settings in v2.03 "fixed" version: (look on the right)
(http://img29.imageshack.us/img29/9028/clipboard01jyf.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-07-05 08:59:40
Don't know if it is by design,but (on inactive window) if I want to click on a button (p.e. for drag'n'drop mode) then I need to click twice (using 2.0.3a).
One click to activate window, second one for the button.
On all other programs I use, this is done with only one click (I mean activating window and performing the function of the button I click)


P.S. please make a small drag'n' dropzone above the batch log zone. It happens so many times that I want drop something and discover that the program is in batch log mode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-05 09:08:05
I'm afraid that's how .NET framework toolbars work, not sure if i can fix it.

As for the batch log, in the next version it will not overlap with drag'n'drop zone/browser. It will be below the main window.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-07-05 18:11:04
Hi Gregory, maybe you've been busy or something, or you just missed my 2 posts (#475 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=643854) and #476 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=643860)) from last weekend, if that's the case, can you check them? When you have time of course. Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-05 21:24:25
I usually answer complex questions when i'm working on a new version, after i've tested it and tried out different ways to fix/change the described/desired program behavior and see how it works. A new version is usually the best answer.

> Or can I only be confident [that my pressing of the CD is ok] when all tracks WITHIN one offset are accurately ripped?
Well yes, but it is almost mathematicly impossible to have all tracks accurately ripped with different offsets, and not have a single offset which fits all tracks.
Let's say track 1 fits offset 555 and track 3 fits offset 666. That means 111 samples were lost somewhere on track 2.
Track 2 will be inaccurate, unless it consists entirely of digital silence.

Being paranoid is part of programmer's job description, so i guess i'll add a check for such cases sooner or later, but from a practical viewpoint i would not worry too much about this.

P.S.: I'm looking at the logs, will reply to that a bit later.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-05 22:24:37
> Why is the "Accurately ripped with offset(s) 0(2)" in the non-verbose log? I thought that "Partial match to pressing(s)" meant that track is NOT accurately ripped.

Current algorithm for nonverbose log is simple:
1) it treats each track separately
2) for each track it answers two different questions separately:
  a) was the track ripped correctly, and with what confidence?
  b) what were the offsets?

The first track was indeed ripped correctly with confidence 9: there were 5 rips matching with offset 12, 2 rips matching with offset 280 and 2 rips matching with offset 1690.
As for offsets, there are 3 entries in the database, each holds 2 CRCs, thus producing 6 possible offset matches (3 possible partial matches and 3 possible complete matches).
Of course each offset should be reported only once. And this would be the case if partial CRCs and complete CRCs were linked in the database, but sometimes they are not, as in this case.
That's why this wierdness showed up. This also made me realize that offsets that lead to partial matches should be listed separately.
Thanks, i'll fix it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radivx on 2009-07-06 01:26:19
Hi,
Thanks a lot for a great program!

Got a small feature request:
Add support for lowercase filenames in the renaming section.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-07-08 03:55:53
I only post to say that I just downgraded from 2.0.3a to 2.0.2a, I don't like the new way of displaying log (the window is too small), I don't like the fact that 2.03a don't recall my flac setting & I don't like that that 2.03a doesn't recall that I always use drag&drop mode. I don't like the fact that I must now set up the default saving folder instead of just using "same folder+append to filename". Overall 2.03 was a painfull experience for me. Lots of useless clicks & wasted time compared to 2.02 which I am happier with.

Not everything is bad, I like "* Compression level selected in the main window" for exemple, but 2.03 is a very little gain for a huge pain from my point of view. Sorry ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-08 08:58:58
That's what experimental versions are for - to find out what works best.
All those problems will be addressed in the next version,
and probably some new problems added

By the way, "same folder+append to filename" works ok in 2.0.3a,
you just have to select the appropriate template from the drop down list:
[%directoryname%\]%filename%-new[%unique%].cue
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-08 09:01:50
Got a small feature request:
Add support for lowercase filenames in the renaming section.

Sounds good.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lioncub on 2009-07-08 17:50:48
Whether there will be a version for linux?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-08 18:06:34
Very likely. Some people already run command-line tools like ArcueDotNet using mono.
This only works with WAV's, but now that CUETools supports external encoders/decoders, flac support can be easily added.
I'm also starting to test UI version with mono. It's not pretty, but it works.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-07-09 13:43:35
I usually answer complex questions when i'm working on a new version, after i've tested it and tried out different ways to fix/change the described/desired program behavior and see how it works. A new version is usually the best answer.

Ok good to know, different approach than devs usually have.. sorry if I pressured.

As for the rest of the stuff concerning AR and your logs, I'm afraid that I've no more time and sadly I'm getting more confused. I've a hard time understanding your answers completely. I think that you're looking at the thing from a technical perspective and I look at it differently. Isn't the whole AR thing meant to be used as verifying whole albums (though technically it checks the tracks separately), not just individual tracks? Maybe here's the problem, people want to verify their albums as a whole, and then your logs looks/presents the results as only thinking of individual tracks (non-verbose log, though the offsets are mentioned but those IMHO are too hard to understand for a "non-propeller hat" user). I dunno, I could be way off.. I'm too confused with this. Thanks for the answers though and your work, I still hope that you could make the logs more understandable (*wink wink* at least remove the "as in pressing(s)" texts).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: WavSlave on 2009-07-10 14:53:06
(I apologize if this is duplicating anything that's already been mentioned in previous posts.  There were just too many to go through at the time.)

Would you please consider sorting the subdirectory list in the file browser pane in a future release?  On FAT32 partitions, subdirectories appear in the order in which they "physically" exist in the directory.  This often leads to non-alphabetized subdirectory lists in the browser pane, making a specific one hard(er) to find.  This isn't an issue on NTFS partitions, of course, just FAT32 partitions.  Yes, a few of us dinosaurs still exist. 

Thanks for at least considering this minor request and thanks to you and Moitah for all your great work up to now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: clampak on 2009-07-10 15:30:36
I'm wondering if I'm missing something- is there a way, in 2.0.3 in the file browser, to have the directories appear in alphabetical order?  The multiselect directories is fabulous, but actually finding the directories is a pain because they're all mixed up.  What order are they in?  There was a post about sorting subdirectory lists on FAT32 partitions, but mine are NTFS and they do not appear sorted either.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-07-10 17:16:51
Thanks for adding the drag'n'drop zone in next version  .

I found another bug (at least I think it is a bug and not by design) in 2.0.2a and 2.0.3a: When selecting Drag'n'drop mode, the Freedb lookup is disabled (greyed out) and no lookup is done.

Also in multiselect mode the freedb lookup is disabled.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-10 18:42:06
Isn't the whole AR thing meant to be used as verifying whole albums

Not really, from a technical perspective. The database itself works on per-track basis.
But in practice that doesn't matter. If all tracks (verified separately) are correct, the whole image is correct.
Exceptions are possible theoreticly, but i've never encounter such rips in practice.
But as i said, i'll add some additional checks just in case, and i'll tidy up log a bit.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-10 18:44:13
I'm wondering if I'm missing something- is there a way, in 2.0.3 in the file browser, to have the directories appear in alphabetical order?  The multiselect directories is fabulous, but actually finding the directories is a pain because they're all mixed up.  What order are they in?  There was a post about sorting subdirectory lists on FAT32 partitions, but mine are NTFS and they do not appear sorted either.

Wierd. I thought .NET does the sorting. Ok, thanks for report. This also reminds me i promissed to add a 'show hidden files' option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-10 18:47:39
I found another bug (at least I think it is a bug and not by design) in 2.0.2a and 2.0.3a: When selecting Drag'n'drop mode, the Freedb lookup is disabled (greyed out) and no lookup is done.
Also in multiselect mode the freedb lookup is disabled.


This is by design. Batch modes are meant to be silent, and what should i do with freedb lookup if i can't show any windows? Silently replace track names with the ones from the first available freedb record? This can be made possible for musicbrainz, which has a lot less discid collisions and higher data quality, but i don't see how it can work with freedb.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-07-10 21:23:48
This is by design. Batch modes are meant to be silent, and what should i do with freedb lookup if i can't show any windows? Silently replace track names with the ones from the first available freedb record? This can be made possible for musicbrainz, which has a lot less discid collisions and higher data quality, but i don't see how it can work with freedb.



For batch mode I think you're correct, but drag'n'drop is not per definition a batch mode.
I often drag just 1 directory in the dropzone and would like to use freedb lookup when I choose encode (to split an image/cue)
You also have a choice of never under freedb lookup, so if people are using drag'n'drop as a batch mode, they can tick that box.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-10 21:43:15
For batch mode I think you're correct, but drag'n'drop is not per definition a batch mode.
I often drag just 1 directory in the dropzone and would like to use freedb lookup when I choose encode (to split an image/cue)
You also have a choice of never under freedb lookup, so if people are using drag'n'drop as a batch mode, they can tick that box.

I guess this requires a new definition for a batch mode.
Ok, i think a batch of one CD must not be considered a batch.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-07-10 23:01:21
I guess this requires a new definition for a batch mode.
Ok, i think a batch of one CD must not be considered a batch.

LOL, I see that my previous post is a bit strangely put, but I hope you know what I mean. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Toif on 2009-07-10 23:19:59
Hello, i use CUETools 2.0.3 x86 and got strange results, when i run it in Verify mode for one APE archive and CUE file.
It show me "Disk not present in database."
But when i remove from CUE one string "REM DISCID AE10AF0D", it show me "(01/01) Accurately ripped as in pressing(s) #1" for all tracks.

Also it show different Disc ID:
001cb4fd-0106ba7b-960e8a0c (without that string in CUE)
001ce185-0108fd63-ae0f220d (with that string in CUE)

Is it intended to work that way?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-10 23:57:08
Hello, i use CUETools 2.0.3 x86 and got strange results, when i run it in Verify mode for one APE archive and CUE file.
It show me "Disk not present in database."
But when i remove from CUE one string "REM DISCID AE10AF0D", it show me "(01/01) Accurately ripped as in pressing(s) #1" for all tracks.

Also it show different Disc ID:
001cb4fd-0106ba7b-960e8a0c (without that string in CUE)
001ce185-0108fd63-ae0f220d (with that string in CUE)

Is it intended to work that way?


Yep. This CD contained a data track. DISCID gave it out.
Without the DISCID CUETools doesn't know about it, and verifies against a (not totally) wrong entry.

Somebody probably made a CD-R copy of that CD, loosing data track in the process, and then ripped it again.
So there's now an entry in the database for the variant of that disc without the data track.

To verify your rip against a real entry and probably get higher confidence values, you have to specify
the length of data track.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-07-11 01:10:12
Not really, from a technical perspective. The database itself works on per-track basis.

Yes, but as an end-user, I can't check individual tracks from AR database. Only whole albums. And I'm only interested to know that my whole album is accurately ripped (though it also means that all the tracks are correct). IMO this is the end-user perspective. And that should matter a lot when designing software.. in general, a common pitfall for devs is to mostly think about technical stuff.

But in practice that doesn't matter. If all tracks (verified separately) are correct, the whole image is correct.

..all tracks within at least one offset, right? Again, IMHO the non-verbose log gives a wrong impression when it combines the AR results from different offsets and lists all tracks just once.. ok, there's the offsets, but like I've written before, those are just too confusing for normal users (I reckon). If I can be so bold for the last time and suggest what changes I think from an end-user perspective would improve the logs (I'm listing all for completeness sake):

1) Quoting again sauvage78: "grouping good results with good results in front & bad results with bad results in the bottom" would be really nice.. especially dividing the results with distinct "Good Results:" and "Bad results:" headers.
2) Bin "as in pressing(s)" texts.
3) Bin "Partial match to pressing(s)" texts, with my limited knowledge, I don't see for what use these could be for. Correct me if I'm wrong.
4) Show only the added up confidence numbers from "whole offset(s) fully accurately ripped" in the non-verbose log.. or better yet, ditch the non-verbose log completely, IMHO if you implement the first 3 points, I think that the full log would be understandable enough for normal users as well.

Sorry if I'm beating a dead horse here. I'm leaving the subject for now and I'll wait for your possible fixes/enhancements. Thanks for listening and tolerating.

P.S. Is it possible to use a separate/"portable" settings.txt file? Let's say If I'd like to use only ArCueDotNet.exe so that the only settings.txt would be in the same directory as the exe. No settings.txt in the \Application Data\CUE Tools\ folder... and if one exists in there, a way to tell the exe to use only the setting file in the directory. Some dll's are probably also needed. Too wild idea?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-07-12 12:35:04
I used filebrowser to be able to use the freedb lookup before splitting an image/cue.
Maybe I'm doing something wrong, but after selecting a directory, choosing encode and clicking Go, the splitting starts without a freedb lookup.
When I click Stop and click Go again, then the freedb lookup is done before the splitting starts.

I'm using 2.0.3.a, selected always under the Freedb lookup and used template [%directoryname%\]new[%unique%]\%filename%.cue
(off topic: I liked the 2.0.2 choices and template possibility more)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-12 15:14:21
P.S. Is it possible to use a separate/"portable" settings.txt file? Let's say If I'd like to use only ArCueDotNet.exe so that the only settings.txt would be in the same directory as the exe. No settings.txt in the \Application Data\CUE Tools\ folder... and if one exists in there, a way to tell the exe to use only the setting file in the directory. Some dll's are probably also needed. Too wild idea?

It works the same as with foobar2000: delete the file "user_profiles_enabled", and settings will become local.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-12 15:21:01
I used filebrowser to be able to use the freedb lookup before splitting an image/cue.
Maybe I'm doing something wrong, but after selecting a directory, choosing encode and clicking Go, the splitting starts without a freedb lookup.
When I click Stop and click Go again, then the freedb lookup is done before the splitting starts.

I'm using 2.0.3.a, selected always under the Freedb lookup and used template [%directoryname%\]new[%unique%]\%filename%.cue
(off topic: I liked the 2.0.2 choices and template possibility more)


That's because you selected a folder, not a CUE sheet.
Currently batch mode is activated if
1) input is a folder
2) input is a multiselect file brower
3) input is drag'n'drop pane
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-07-12 17:28:40
It works the same as with foobar2000: delete the file "user_profiles_enabled", and settings will become local.
Ok, didn't know, I don't use fb2k. It seems that ArCueDotNet.exe does NOT use any settings.txt file at all. Can you confirm this? I changed the AR verbose off from the main app settings & ran ArCueDotNet = still shows the verbose output.

One bug/problem found:

1) Rename *\Application Data\CUE Tools\settings.txt file (if you've "user_profiles_enabled", otherwise from the app "install" folder)
2) Start and close CUETools.exe
3) Compare the newly created settings file to the old renamed

= there are several lines that are missing in the new settings file:
Code: [Select]
ExternalEncoder7Name=lame -V2
ExternalEncoder7Extension=mp3
ExternalEncoder7Path=lame.exe
ExternalEncoder7Parameters=--vbr-new -V2 - %O
ExternalEncoder7Lossless=0
ExternalEncoder7Modes=
ExternalEncoder7Mode=
ExternalEncoder8Name=lame -V0
ExternalEncoder8Extension=mp3
ExternalEncoder8Path=lame.exe
ExternalEncoder8Parameters=--vbr-new -V0 - %O
ExternalEncoder8Lossless=0
ExternalEncoder8Modes=
ExternalEncoder8Mode=
ExternalEncoder9Name=lame 256
ExternalEncoder9Extension=mp3
ExternalEncoder9Path=lame.exe
ExternalEncoder9Parameters=-m s -q 0 -b 256 --noreplaygain - %O
ExternalEncoder9Lossless=0
ExternalEncoder9Modes=
ExternalEncoder9Mode=
ExternalEncoder10Name=lame 320
ExternalEncoder10Extension=mp3
ExternalEncoder10Path=lame.exe
ExternalEncoder10Parameters=-m s -q 0 -b 320 --noreplaygain - %O
ExternalEncoder10Lossless=0
ExternalEncoder10Modes=
ExternalEncoder10Mode=
ExternalEncoders=11
(the first line is actually only different, not missing)

Or it's the other way around, the previous versions had those lines and the newer version doesn't, but failed to remove the obsolete lines from the settings.txt file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-12 18:31:53
> It seems that ArCueDotNet.exe does NOT use any settings.txt file at all.
That is correct. There are not many settings that affect verification, so this was not needed in the past.
I'm considering three options at the moment:
1) Use CUETools settings for ArCueDotNet
2) Add several command line options for ArCueDotNet
3) Use the 'profiles' system that will be introduced in the next version, so that ArCueDotNet would have a separate options profile, configurable with CUETools.

> there are several lines that are missing in the new settings file:
New CUETools versions introduce new external encoders, which sometimes obsolete older ones.
I see no reason to force the removal of the encoders used in prior versions.
Encoders can be always added/removed from the settings interface.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-07-12 22:13:01
Encoders can be always added/removed from the settings interface.

Just tried and I was able to remove by selecting an encoder and pressing DEL, not much luck with adding, how does that happen? The add/remove functionality is a bit hidden now don't you think? Anyways, thanks a million for the answers again, can't wait to see new improved versions.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-07-14 03:14:04
Feature request:
A job queue, so CUETools can process another file while displaying the log for a finished one.
(And I could set a few jobs and leave it alone for a while.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Boiled Beans on 2009-07-14 08:17:51
Is it possible to force CUETools to remember the encoder settings? Every time I start CUETools, the FLAC encoder setting reverts back to level 5 so I have to change it to 8 every time.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Toif on 2009-07-15 00:02:36
Gregory S. Chudov, thank you very much for your reply! That's clear for me now

I have one more question. While checking some files i found strange thing (at least for me).

Both CD images pass checking with exactly same result, both had same "Disc ID", both had same CRC in "Track   [ CRC    ] Status". At the same time CRC-32 for last track different and last 251 bytes for files different too (one had all zeros there).

So, my question here - how that could be possible?

Like i understand AccurateRip had much more higher collisions probabilities than CRC-32? If that true what reason to use it? And why not replace it with any strong hash, like Whirlpool, for example?

Thanks for your help and your excellent program!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-07-15 00:25:22
So, my question here - how that could be possible?

AR hashes do not include the first five sectors of the first track and the last five sectors of the last track to account for drives with different offsets that cannot overread.

Regarding what reason to use the algorithm for AR, you'll have to ask Spoon.  As it stands right now, it's a good thing that the calculation is how it is since offset calculations for different pressings might otherwise not be possible.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fuki on 2009-07-19 22:34:34
First of all, thank you for CUE TOOLS and AR!
The AR (and its support via CueTools) is the best thing I've seen in years!
Thank you Gregory and thank you Spoon!

I've been browsing this forum for a few days now and I have a question.

I have a Frank Sinatra disc burned with wrong offset. It should have been burned with offset 646 for AR to be correct, but it wasn't (BTW that was a loooong time ago), so I used CueTools to find out the correct offset. The problem is that if there are more than 10 offset results, CueTools display only first 10. And what if the correct offset value is within next 10 results? Is is possible to find out all possible offsets at once?

Here are the logs when used with Offset value 0 and Offset value 646.

Frank Sinatra - My way (The best of) (Disc 1 of 2) - Offset 0.accurip
Code: [Select]
[Verification date: 19.7.2009 22:43:28]
[Disc ID: 003f8c07-0449c4d5-6f11b918]
Track    [ CRC    ] Status
01    [f585f0db] (00/350) No matches
02    [e87aa389] (00/349) No matches
03    [6f188cd8] (00/352) No matches
04    [e8633fa4] (00/348) No matches
05    [6b8a2af2] (00/353) No matches
06    [0a1f40ef] (00/350) No matches
07    [51a0886a] (00/346) No matches
08    [2de0bec2] (00/352) No matches
09    [6b42e62c] (00/352) No matches
10    [5b8d9cc4] (00/353) No matches
11    [bafb300d] (00/351) No matches
12    [12bc5640] (00/351) No matches
13    [4d669d12] (00/352) No matches
14    [4b5e8a52] (00/351) No matches
15    [53f807e9] (00/347) No matches
16    [b16e0405] (00/342) No matches
17    [b94c46d4] (00/346) No matches
18    [4cfd596a] (00/351) No matches
19    [8692f3e0] (00/347) No matches
20    [21a699ef] (00/349) No matches
21    [32cf2606] (00/344) No matches
22    [a8b563d3] (00/343) No matches
23    [f9704ecf] (00/340) No matches
24    [e3161251] (00/328) No matches
Offsetted by -2120:
01    [dea3dd6c] (14/350) Partial match to pressing(s) #6
02    [354f43f8] (12/349) Partial match to pressing(s) #7
03    [e87380e4] (14/352) Accurately ripped as in pressing(s) #6
04    [a5bd3052] (13/348) Accurately ripped as in pressing(s) #7
05    [c3a59766] (13/353) Accurately ripped as in pressing(s) #7
06    [23d15c5d] (13/350) Partial match to pressing(s) #7
07    [f00891f6] (13/346) Accurately ripped as in pressing(s) #7
08    [eb57e268] (14/352) Accurately ripped as in pressing(s) #6
09    [7e7527fd] (13/352) Accurately ripped as in pressing(s) #7
10    [b70a7588] (13/353) Partial match to pressing(s) #7
11    [0620bbaf] (13/351) Partial match to pressing(s) #7
12    [aeacd3ed] (12/351) Accurately ripped as in pressing(s) #7
13    [3e17d760] (14/352) Accurately ripped as in pressing(s) #7
14    [ab2fb86b] (13/351) Accurately ripped as in pressing(s) #7
15    [fb64be81] (13/347) Accurately ripped as in pressing(s) #7
16    [fd0596a0] (13/342) Accurately ripped as in pressing(s) #7
17    [4e1b6e5b] (13/346) Accurately ripped as in pressing(s) #7
18    [03034e4d] (14/351) Accurately ripped as in pressing(s) #7
19    [398067c6] (13/347) Partial match to pressing(s) #7
20    [52e48a37] (13/349) Partial match to pressing(s) #7
21    [704c7574] (11/344) Partial match to pressing(s) #7
22    [a0f98e4d] (13/343) Accurately ripped as in pressing(s) #7
23    [217e041a] (11/340) Accurately ripped as in pressing(s) #7
24    [eda53bea] (11/328) Accurately ripped as in pressing(s) #7
Offsetted by -1574:
01    [3acdb1d9] (06/350) Partial match to pressing(s) #11
02    [784520c5] (06/349) Partial match to pressing(s) #11
03    [b3b3532d] (06/352) Accurately ripped as in pressing(s) #11
04    [3cc3c3e6] (06/348) Accurately ripped as in pressing(s) #11
05    [ea4d76a3] (06/353) Accurately ripped as in pressing(s) #11
06    [e6daa35c] (07/350) Partial match to pressing(s) #10
07    [377704c5] (06/346) Accurately ripped as in pressing(s) #11
08    [f3e94ab8] (06/352) Accurately ripped as in pressing(s) #10
09    [f4de3c8a] (06/352) Accurately ripped as in pressing(s) #11
10    [f3120423] (06/353) Partial match to pressing(s) #11
11    [2e963fb4] (06/351) Partial match to pressing(s) #11
12    [513bfb54] (06/351) Accurately ripped as in pressing(s) #11
13    [56f0795e] (06/352) Accurately ripped as in pressing(s) #11
14    [b691d7a4] (06/351) Accurately ripped as in pressing(s) #11
15    [176e787c] (06/347) Accurately ripped as in pressing(s) #11
16    [7c7e9c8e] (06/342) Accurately ripped as in pressing(s) #11
17    [ab6f54c2] (06/346) Accurately ripped as in pressing(s) #11
18    [ad4df5ed] (06/351) Accurately ripped as in pressing(s) #11
19    [91930fa7] (05/347) Accurately ripped as in pressing(s) #11
20    [c673be15] (06/349) Partial match to pressing(s) #11
21    [f5d361ad] (06/344) Partial match to pressing(s) #11
22    [136a4373] (06/343) Accurately ripped as in pressing(s) #11
23    [bc85ab8e] (06/340) Accurately ripped as in pressing(s) #11
24    [9bbaf737] (03/328) Accurately ripped as in pressing(s) #11
Offsetted by -1554:
01    [e23e885f] (08/350) Partial match to pressing(s) #9
02    [c07a1e27] (07/349) Partial match to pressing(s) #10
03    [11969057] (08/352) Accurately ripped as in pressing(s) #8
04    [4d234817] (08/348) Accurately ripped as in pressing(s) #8
05    [378b5551] (08/353) Accurately ripped as in pressing(s) #9
06    [5cd52879] (08/350) Partial match to pressing(s) #9
07    [eeaf01c3] (08/346) Accurately ripped as in pressing(s) #9
08    [00de3ab8] (08/352) Accurately ripped as in pressing(s) #9
09    [306796f6] (08/352) Accurately ripped as in pressing(s) #9
10    [6c4204e1] (08/353) Partial match to pressing(s) #9
11    [a72800f0] (08/351) Partial match to pressing(s) #9
12    [6019c03a] (08/351) Accurately ripped as in pressing(s) #9
13    [4c275f4b] (08/352) Accurately ripped as in pressing(s) #9
14    [01dff763] (08/351) Accurately ripped as in pressing(s) #9
15    [03a811f7] (08/347) Accurately ripped as in pressing(s) #8
16    [c5f91cc5] (07/342) Accurately ripped as in pressing(s) #10
17    [60aa109a] (08/346) Accurately ripped as in pressing(s) #8
18    [fcd5f9b8] (08/351) Accurately ripped as in pressing(s) #9
19    [44b88826] (08/347) Partial match to pressing(s) #9
20    [764a1a01] (07/349) Partial match to pressing(s) #9
21    [d6f6b757] (08/344) Partial match to pressing(s) #9
22    [3a73eae9] (08/343) Accurately ripped as in pressing(s) #8
23    [eca08582] (07/340) Accurately ripped as in pressing(s) #10
24    [a8f8d113] (08/328) Accurately ripped as in pressing(s) #8
Offsetted by -1456:
01    [dd2b5d17] (06/350) Partial match to pressing(s) #10
02    [33741389] (07/349) Partial match to pressing(s) #9
03    [9945a10a] (07/352) Accurately ripped as in pressing(s) #9
04    [3d8ab9f1] (07/348) Accurately ripped as in pressing(s) #9
05    [310ae7c3] (07/353) Accurately ripped as in pressing(s) #10
06    [dab44216] (07/350) Partial match to pressing(s) #11
07    [97ccba71] (07/346) Accurately ripped as in pressing(s) #10
08    [5029f6bc] (06/352) Accurately ripped as in pressing(s) #11
09    [42df52dd] (07/352) Accurately ripped as in pressing(s) #10
10    [0659ff45] (07/353) Partial match to pressing(s) #10
11    [c0287ca8] (06/351) Partial match to pressing(s) #10
12    [18e85477] (07/351) Accurately ripped as in pressing(s) #10
13    [34ca22e6] (07/352) Accurately ripped as in pressing(s) #10
14    [12a6e6c7] (07/351) Accurately ripped as in pressing(s) #10
15    [2c287cc8] (07/347) Accurately ripped as in pressing(s) #9
16    [50033067] (07/342) Accurately ripped as in pressing(s) #9
17    [abaa883c] (07/346) Accurately ripped as in pressing(s) #9
18    [afabc9d7] (07/351) Accurately ripped as in pressing(s) #10
19    [f4086c21] (07/347) Partial match to pressing(s) #10
20    [ed7e0f9f] (07/349) Partial match to pressing(s) #10
21    [43e2aa01] (07/344) Partial match to pressing(s) #10
22    [64cc6957] (07/343) Accurately ripped as in pressing(s) #9
23    [75326b19] (07/340) Accurately ripped as in pressing(s) #8
24    [32293bfc] (06/328) Accurately ripped as in pressing(s) #10
Offsetted by -775:
01    [7700430c] (03/350) Partial match to pressing(s) #12
02    [9b0e85ab] (03/349) Partial match to pressing(s) #12
03    [796d0925] (03/352) Accurately ripped as in pressing(s) #12
04    [e119779e] (03/348) Accurately ripped as in pressing(s) #12
05    [78e7df9a] (03/353) Accurately ripped as in pressing(s) #12
06    [5150b641] (03/350) Partial match to pressing(s) #12
07    [7a069032] (03/346) Accurately ripped as in pressing(s) #12
08    [c38d9244] (03/352) Accurately ripped as in pressing(s) #12
09    [ce59b738] (03/352) Accurately ripped as in pressing(s) #12
10    [e540a9b7] (03/353) Partial match to pressing(s) #12
11    [38ed3dcb] (03/351) Partial match to pressing(s) #12
12    [e8a1f2d4] (03/351) Accurately ripped as in pressing(s) #12
13    [68e76886] (03/352) Accurately ripped as in pressing(s) #12
14    [66a22799] (03/351) Accurately ripped as in pressing(s) #12
15    [0625e200] (03/347) Accurately ripped as in pressing(s) #12
16    [43ff0f99] (03/342) Accurately ripped as in pressing(s) #12
17    [a6713e86] (03/346) Accurately ripped as in pressing(s) #13
18    [d34ce712] (03/351) Accurately ripped as in pressing(s) #12
19    [603c8cb8] (03/347) Partial match to pressing(s) #12
20    [c3f42ff6] (03/349) Partial match to pressing(s) #12
21    [3ad8bf82] (03/344) Partial match to pressing(s) #12
22    [b411e06d] (03/343) Accurately ripped as in pressing(s) #12
23    [ef344d99] (02/340) Accurately ripped as in pressing(s) #12
24    [1c2373af] (02/328) Accurately ripped as in pressing(s) #14
Offsetted by -621:
01    [2544f780] (57/350) Partial match to pressing(s) #3
02    [36d860db] (57/349) Partial match to pressing(s) #3
03    [37403730] (58/352) Accurately ripped as in pressing(s) #3
04    [5db4f67b] (57/348) Accurately ripped as in pressing(s) #3
05    [a7ff57d3] (57/353) Accurately ripped as in pressing(s) #3
06    [5a056abb] (57/350) Partial match to pressing(s) #3
07    [1b3bb2fb] (56/346) Accurately ripped as in pressing(s) #3
08    [54be7c94] (58/352) Accurately ripped as in pressing(s) #3
09    [b40549ba] (58/352) Accurately ripped as in pressing(s) #3
10    [f50fa7a1] (57/353) Partial match to pressing(s) #3
11    [a7447b3d] (58/351) Partial match to pressing(s) #3
12    [cb4fb9c6] (58/351) Accurately ripped as in pressing(s) #3
13    [04e897e5] (57/352) Accurately ripped as in pressing(s) #3
14    [d76e1bdc] (57/351) Accurately ripped as in pressing(s) #3
15    [abd17181] (57/347) Accurately ripped as in pressing(s) #3
16    [11a65a85] (54/342) Accurately ripped as in pressing(s) #3
17    [765ac4c3] (54/346) Accurately ripped as in pressing(s) #3
18    [17607cf6] (57/351) Accurately ripped as in pressing(s) #3
19    [b18cae6e] (56/347) Accurately ripped as in pressing(s) #3
20    [5ab38d5c] (56/349) Partial match to pressing(s) #3
21    [858dd6da] (56/344) Partial match to pressing(s) #3
22    [808ca234] (55/343) Accurately ripped as in pressing(s) #3
23    [48ada768] (55/340) Accurately ripped as in pressing(s) #3
24    [d0cfc45d] (52/328) Accurately ripped as in pressing(s) #3
Offsetted by -616:
01    [c851a0b5] (39/350) Partial match to pressing(s) #4
02    [592b5af5] (39/349) Partial match to pressing(s) #4
03    [ab9307fc] (38/352) Accurately ripped as in pressing(s) #4
04    [fa1014db] (37/348) Accurately ripped as in pressing(s) #4
05    [538cf68e] (39/353) Accurately ripped as in pressing(s) #4
06    [b81f4996] (38/350) Partial match to pressing(s) #4
07    [970463a0] (37/346) Accurately ripped as in pressing(s) #4
08    [62a0bad4] (38/352) Accurately ripped as in pressing(s) #4
09    [2db457b9] (37/352) Accurately ripped as in pressing(s) #4
10    [e680fa9c] (39/353) Partial match to pressing(s) #4
11    [f482346d] (38/351) Partial match to pressing(s) #4
12    [693476df] (38/351) Accurately ripped as in pressing(s) #4
13    [5dee2163] (38/352) Accurately ripped as in pressing(s) #4
14    [a0e2ab4d] (38/351) Accurately ripped as in pressing(s) #4
15    [0c508e43] (37/347) Accurately ripped as in pressing(s) #4
16    [b4fa8927] (37/342) Accurately ripped as in pressing(s) #4
17    [d8adac03] (38/346) Accurately ripped as in pressing(s) #4
18    [ecc9bfe9] (37/351) Accurately ripped as in pressing(s) #4
19    [e93d4a26] (38/347) Accurately ripped as in pressing(s) #4
20    [c6a92457] (38/349) Partial match to pressing(s) #4
21    [07fac8a6] (38/344) Partial match to pressing(s) #4
22    [7c285b23] (37/343) Accurately ripped as in pressing(s) #4
23    [289241d6] (37/340) Accurately ripped as in pressing(s) #4
24    [97bfba4a] (36/328) Accurately ripped as in pressing(s) #4
Offsetted by -243:
01    [8d00083f] (08/350) Partial match to pressing(s) #8
02    [ace4937a] (08/349) Partial match to pressing(s) #8
03    [928b3af2] (07/352) Accurately ripped as in pressing(s) #10
04    [f834092b] (07/348) Accurately ripped as in pressing(s) #10
05    [e3fa2d58] (08/353) Accurately ripped as in pressing(s) #8
06    [d418c2fe] (08/350) Partial match to pressing(s) #8
07    [3c88a3f5] (08/346) Accurately ripped as in pressing(s) #8
08    [264a05ee] (08/352) Accurately ripped as in pressing(s) #8
09    [8bb98290] (08/352) Accurately ripped as in pressing(s) #8
10    [16bfb34b] (08/353) Partial match to pressing(s) #8
11    [09c2c598] (08/351) Partial match to pressing(s) #8
12    [5b358548] (08/351) Accurately ripped as in pressing(s) #8
13    [92ce4f06] (08/352) Accurately ripped as in pressing(s) #8
14    [8f47d827] (08/351) Accurately ripped as in pressing(s) #8
15    [0acaa3c3] (07/347) Accurately ripped as in pressing(s) #10
16    [20146d12] (08/342) Accurately ripped as in pressing(s) #8
17    [400fff9c] (07/346) Accurately ripped as in pressing(s) #10
18    [84e54b4c] (08/351) Accurately ripped as in pressing(s) #8
19    [d7a9ecd5] (08/347) Accurately ripped as in pressing(s) #8
20    [6fa089e2] (08/349) Partial match to pressing(s) #8
21    [3ced3eb2] (08/344) Partial match to pressing(s) #8
22    [7d1b3bda] (07/343) Accurately ripped as in pressing(s) #10
23    [efd4a204] (07/340) Accurately ripped as in pressing(s) #9
24    [df768157] (07/328) Accurately ripped as in pressing(s) #9
Offsetted by -18:
01    [fc94894e] (23/350) Accurately ripped as in pressing(s) #5
02    [a49a3b06] (23/349) Accurately ripped as in pressing(s) #5
03    [bb1af35b] (23/352) Accurately ripped as in pressing(s) #5
04    [c6d5bf2f] (23/348) Accurately ripped as in pressing(s) #5
05    [6c28cf7c] (23/353) Accurately ripped as in pressing(s) #5
06    [360d027f] (23/350) Accurately ripped as in pressing(s) #5
07    [c460e985] (23/346) Accurately ripped as in pressing(s) #5
08    [ddafb11b] (23/352) Accurately ripped as in pressing(s) #5
09    [3d264754] (23/352) Accurately ripped as in pressing(s) #5
10    [0e84371e] (23/353) Accurately ripped as in pressing(s) #5
11    [6c16439f] (23/351) Accurately ripped as in pressing(s) #5
12    [ac3808c3] (23/351) Accurately ripped as in pressing(s) #5
13    [b88f6dfe] (23/352) Accurately ripped as in pressing(s) #5
14    [a8d7375c] (23/351) Accurately ripped as in pressing(s) #5
15    [a4c9f84c] (23/347) Accurately ripped as in pressing(s) #5
16    [50eb2b2e] (23/342) Accurately ripped as in pressing(s) #5
17    [e502d039] (23/346) Accurately ripped as in pressing(s) #5
18    [bd73e23d] (23/351) Accurately ripped as in pressing(s) #5
19    [752ee5c9] (23/347) Accurately ripped as in pressing(s) #5
20    [69cc1401] (23/349) Accurately ripped as in pressing(s) #5
21    [2a13bf8e] (23/344) Accurately ripped as in pressing(s) #5
22    [0e689d59] (23/343) Accurately ripped as in pressing(s) #5
23    [add7fc1d] (22/340) Accurately ripped as in pressing(s) #5
24    [708afe39] (22/328) Accurately ripped as in pressing(s) #5
Offsetted by -8:
01    [4a241e34] (13/350) Accurately ripped as in pressing(s) #7
02    [49a956b6] (13/349) Accurately ripped as in pressing(s) #6
03    [43bbadea] (13/352) Accurately ripped as in pressing(s) #7
04    [1293a529] (14/348) Accurately ripped as in pressing(s) #6
05    [7f734f4d] (14/353) Accurately ripped as in pressing(s) #6
06    [ae1f7abe] (13/350) Accurately ripped as in pressing(s) #6
07    [8bfc8fd8] (13/346) Accurately ripped as in pressing(s) #6
08    [0a282a81] (13/352) Accurately ripped as in pressing(s) #7
09    [f8df2dcc] (14/352) Accurately ripped as in pressing(s) #6
10    [720dc4ec] (14/353) Accurately ripped as in pressing(s) #6
11    [52cc8e15] (13/351) Accurately ripped as in pressing(s) #6
12    [372ddb7c] (13/351) Accurately ripped as in pressing(s) #6
13    [131bc509] (14/352) Accurately ripped as in pressing(s) #6
14    [8578f3bf] (14/351) Accurately ripped as in pressing(s) #6
15    [b11839c5] (13/347) Accurately ripped as in pressing(s) #6
16    [44b7dcb1] (13/342) Accurately ripped as in pressing(s) #6
17    [aa617466] (15/346) Accurately ripped as in pressing(s) #6
18    [13990e47] (14/351) Accurately ripped as in pressing(s) #6
19    [f09a267d] (14/347) Accurately ripped as in pressing(s) #6
20    [41b741f7] (15/349) Accurately ripped as in pressing(s) #6
21    [2eeda326] (13/344) Accurately ripped as in pressing(s) #6
22    [2b3def2b] (14/343) Accurately ripped as in pressing(s) #6
23    [9ef3b847] (14/340) Accurately ripped as in pressing(s) #6
24    [0582ecf1] (15/328) Accurately ripped as in pressing(s) #6
Offsetted by 48:
01    [aa5a57c4] (67/350) Partial match to pressing(s) #2
02    [b2bed2f8] (66/349) Partial match to pressing(s) #2
03    [cbaad6ae] (67/352) Accurately ripped as in pressing(s) #2
04    [daf68e05] (65/348) Accurately ripped as in pressing(s) #2
05    [231964d6] (67/353) Accurately ripped as in pressing(s) #2
06    [312c3a6d] (66/350) Partial match to pressing(s) #2
07    [f7d2c1ca] (65/346) Accurately ripped as in pressing(s) #2
08    [08533681] (67/352) Accurately ripped as in pressing(s) #2
09    [60448b84] (67/352) Accurately ripped as in pressing(s) #2
10    [c294ab4c] (67/353) Partial match to pressing(s) #2
11    [531c68e3] (67/351) Partial match to pressing(s) #2
12    [e66a5a98] (67/351) Accurately ripped as in pressing(s) #2
13    [210c6d09] (67/352) Accurately ripped as in pressing(s) #2
14    [ecd46bb9] (67/351) Accurately ripped as in pressing(s) #2
15    [e6a92113] (66/347) Accurately ripped as in pressing(s) #2
16    [296c3044] (65/342) Accurately ripped as in pressing(s) #2
17    [703f0aec] (66/346) Accurately ripped as in pressing(s) #2
18    [888f83f1] (67/351) Accurately ripped as in pressing(s) #2
19    [0b5ec54c] (65/347) Accurately ripped as in pressing(s) #2
20    [6142a9bf] (67/349) Partial match to pressing(s) #2
21    [4a183746] (64/344) Partial match to pressing(s) #2
22    [2ed31fc3] (65/343) Accurately ripped as in pressing(s) #2
23    [1822d5ff] (67/340) Accurately ripped as in pressing(s) #2
24    [1488f291] (58/328) Accurately ripped as in pressing(s) #2
More than 10 offsets match!

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
--    [45FDDEB1]    [2DA549EC]      CRC32  
01    [0F1F5F5A]    [DA3937E5]    
02    [845FC3FB]    [BEEBFA2C]    
03    [74AD891D]    [1C1148E6]    
04    [DC980D79]    [47A964C6]    
05    [A29BA010]    [3E89ABB7]    
06    [720AF15C]    [0C9069B1]    
07    [C763B2FC]    [A3BAFC5D]    
08    [8DB001C5]    [F1971856]    
09    [C36566C1]    [5813076C]    
10    [BA4873F5]    [49B1459B]    
11    [FB3F5A42]    [3551181C]    
12    [57FF9816]    [B0385C69]    
13    [565FBCF6]    [B1D9CAEB]    
14    [E6D7C765]    [D4260612]    
15    [2D427660]    [804EF9E2]    
16    [1D3FD79F]    [247EDF75]    
17    [BF43DD62]    [09FD2629]    
18    [5579C2B6]    [434826CC]    
19    [1B702288]    [A964F959]    
20    [5608BD7B]    [D58FF562]    
21    [2D50EBC5]    [FA8A9614]    
22    [C75FF9F1]    [0257C9E3]    
23    [ACB2EBD3]    [F06A56F6]    
24    [DD1BC702]    [BC168A99]


Frank Sinatra - My way (The best of) (Disc 1 of 2) - Offset 646.accurip
[code][Verification date: 19.7.2009 22:42:31]
[Disc ID: 003f8c07-0449c4d5-6f11b918]
Offset applied: 646
Track    [ CRC    ] Status
01    [2d662954] (106/350) Accurately ripped as in pressing(s) #1
02    [74e86106] (108/349) Accurately ripped as in pressing(s) #1
03    [30a8c093] (108/352) Accurately ripped as in pressing(s) #1
04    [954e2900] (108/348) Accurately ripped as in pressing(s) #1
05    [c4aacf91] (108/353) Accurately ripped as in pressing(s) #1
06    [e94eda30] (107/350) Accurately ripped as in pressing(s) #1
07    [87e84da5] (107/346) Accurately ripped as in pressing(s) #1
08    [4a5f8e32] (108/352) Accurately ripped as in pressing(s) #1
09    [bedb4173] (108/352) Accurately ripped as in pressing(s) #1
10    [4d0f24ef] (108/353) Accurately ripped as in pressing(s) #1
11    [87a659bd] (108/351) Accurately ripped as in pressing(s) #1
12    [2332419c] (108/351) Accurately ripped as in pressing(s) #1
13    [8fad5926] (107/352) Accurately ripped as in pressing(s) #1
14    [24352540] (107/351) Accurately ripped as in pressing(s) #1
15    [494f9a03] (107/347) Accurately ripped as in pressing(s) #1
16    [96ce2e41] (106/342) Accurately ripped as in pressing(s) #1
17    [7454b4ee] (103/346) Accurately ripped as in pressing(s) #1
18    [be8bf862] (107/351) Accurately ripped as in pressing(s) #1
19    [5788d92e] (107/347) Accurately ripped as in pressing(s) #1
20    [04659969] (106/349) Accurately ripped as in pressing(s) #1
21    [6c312e2e] (107/344) Accurately ripped as in pressing(s) #1
22    [02dbeb6f] (105/343) Accurately ripped as in pressing(s) #1
23    [1682fd17] (105/340) Accurately ripped as in pressing(s) #1
24    [3bb81c59] (104/328) Accurately ripped as in pressing(s) #1
Offsetted by -2766:
01    [dea3dd6c] (14/350) Partial match to pressing(s) #6
02    [354f43f8] (12/349) Partial match to pressing(s) #7
03    [e87380e4] (14/352) Accurately ripped as in pressing(s) #6
04    [a5bd3052] (13/348) Accurately ripped as in pressing(s) #7
05    [c3a59766] (13/353) Accurately ripped as in pressing(s) #7
06    [23d15c5d] (13/350) Partial match to pressing(s) #7
07    [f00891f6] (13/346) Accurately ripped as in pressing(s) #7
08    [eb57e268] (14/352) Accurately ripped as in pressing(s) #6
09    [7e7527fd] (13/352) Accurately ripped as in pressing(s) #7
10    [b70a7588] (13/353) Partial match to pressing(s) #7
11    [0620bbaf] (13/351) Partial match to pressing(s) #7
12    [aeacd3ed] (12/351) Accurately ripped as in pressing(s) #7
13    [3e17d760] (14/352) Accurately ripped as in pressing(s) #7
14    [ab2fb86b] (13/351) Accurately ripped as in pressing(s) #7
15    [fb64be81] (13/347) Accurately ripped as in pressing(s) #7
16    [fd0596a0] (13/342) Accurately ripped as in pressing(s) #7
17    [4e1b6e5b] (13/346) Accurately ripped as in pressing(s) #7
18    [03034e4d] (14/351) Accurately ripped as in pressing(s) #7
19    [398067c6] (13/347) Partial match to pressing(s) #7
20    [52e48a37] (13/349) Partial match to pressing(s) #7
21    [704c7574] (11/344) Partial match to pressing(s) #7
22    [a0f98e4d] (13/343) Accurately ripped as in pressing(s) #7
23    [217e041a] (11/340) Accurately ripped as in pressing(s) #7
24    [eda53bea] (11/328) Accurately ripped as in pressing(s) #7
Offsetted by -2220:
01    [3acdb1d9] (06/350) Partial match to pressing(s) #11
02    [784520c5] (06/349) Partial match to pressing(s) #11
03    [b3b3532d] (06/352) Accurately ripped as in pressing(s) #11
04    [3cc3c3e6] (06/348) Accurately ripped as in pressing(s) #11
05    [ea4d76a3] (06/353) Accurately ripped as in pressing(s) #11
06    [e6daa35c] (07/350) Partial match to pressing(s) #10
07    [377704c5] (06/346) Accurately ripped as in pressing(s) #11
08    [f3e94ab8] (06/352) Accurately ripped as in pressing(s) #10
09    [f4de3c8a] (06/352) Accurately ripped as in pressing(s) #11
10    [f3120423] (06/353) Partial match to pressing(s) #11
11    [2e963fb4] (06/351) Partial match to pressing(s) #11
12    [513bfb54] (06/351) Accurately ripped as in pressing(s) #11
13    [56f0795e] (06/352) Accurately ripped as in pressing(s) #11
14    [b691d7a4] (06/351) Accurately ripped as in pressing(s) #11
15    [176e787c] (06/347) Accurately ripped as in pressing(s) #11
16    [7c7e9c8e] (06/342) Accurately ripped as in pressing(s) #11
17    [ab6f54c2] (06/346) Accurately ripped as in pressing(s) #11
18    [ad4df5ed] (06/351) Accurately ripped as in pressing(s) #11
19    [91930fa7] (05/347) Accurately ripped as in pressing(s) #11
20    [c673be15] (06/349) Partial match to pressing(s) #11
21    [f5d361ad] (06/344) Partial match to pressing(s) #11
22    [136a4373] (06/343) Accurately ripped as in pressing(s) #11
23    [bc85ab8e] (06/340) Accurately ripped as in pressing(s) #11
24    [9bbaf737] (03/328) Accurately ripped as in pressing(s) #11
Offsetted by -2200:
01    [e23e885f] (08/350) Partial match to pressing(s) #9
02    [c07a1e27] (07/349) Partial match to pressing(s) #10
03    [11969057] (08/352) Accurately ripped as in pressing(s) #8
04    [4d234817] (08/348) Accurately ripped as in pressing(s) #8
05    [378b5551] (08/353) Accurately ripped as in pressing(s) #9
06    [5cd52879] (08/350) Partial match to pressing(s) #9
07    [eeaf01c3] (08/346) Accurately ripped as in pressing(s) #9
08    [00de3ab8] (08/352) Accurately ripped as in pressing(s) #9
09    [306796f6] (08/352) Accurately ripped as in pressing(s) #9
10    [6c4204e1] (08/353) Partial match to pressing(s) #9
11    [a72800f0] (08/351) Partial match to pressing(s) #9
12    [6019c03a] (08/351) Accurately ripped as in pressing(s) #9
13    [4c275f4b] (08/352) Accurately ripped as in pressing(s) #9
14    [01dff763] (08/351) Accurately ripped as in pressing(s) #9
15    [03a811f7] (08/347) Accurately ripped as in pressing(s) #8
16    [c5f91cc5] (07/342) Accurately ripped as in pressing(s) #10
17    [60aa109a] (08/346) Accurately ripped as in pressing(s) #8
18    [fcd5f9b8] (08/351) Accurately ripped as in pressing(s) #9
19    [44b88826] (08/347) Partial match to pressing(s) #9
20    [764a1a01] (07/349) Partial match to pressing(s) #9
21    [d6f6b757] (08/344) Partial match to pressing(s) #9
22    [3a73eae9] (08/343) Accurately ripped as in pressing(s) #8
23    [eca08582] (07/340) Accurately ripped as in pressing(s) #10
24    [a8f8d113] (08/328) Accurately ripped as in pressing(s) #8
Offsetted by -2102:
01    [dd2b5d17] (06/350) Partial match to pressing(s) #10
02    [33741389] (07/349) Partial match to pressing(s) #9
03    [9945a10a] (07/352) Accurately ripped as in pressing(s) #9
04    [3d8ab9f1] (07/348) Accurately ripped as in pressing(s) #9
05    [310ae7c3] (07/353) Accurately ripped as in pressing(s) #10
06    [dab44216] (07/350) Partial match to pressing(s) #11
07    [97ccba71] (07/346) Accurately ripped as in pressing(s) #10
08    [5029f6bc] (06/352) Accurately ripped as in pressing(s) #11
09    [42df52dd] (07/352) Accurately ripped as in pressing(s) #10
10    [0659ff45] (07/353) Partial match to pressing(s) #10
11    [c0287ca8] (06/351) Partial match to pressing(s) #10
12    [18e85477] (07/351) Accurately ripped as in pressing(s) #10
13    [34ca22e6] (07/352) Accurately ripped as in pressing(s) #10
14    [12a6e6c7] (07/351) Accurately ripped as in pressing(s) #10
15    [2c287cc8] (07/347) Accurately ripped as in pressing(s) #9
16    [50033067] (07/342) Accurately ripped as in pressing(s) #9
17    [abaa883c] (07/346) Accurately ripped as in pressing(s) #9
18    [afabc9d7] (07/351) Accurately ripped as in pressing(s) #10
19    [f4086c21] (07/347) Partial match to pressing(s) #10
20    [ed7e0f9f] (07/349) Partial match to pressing(s) #10
21    [43e2aa01] (07/344) Partial match to pressing(s) #10
22    [64cc6957] (07/343) Accurately ripped as in pressing(s) #9
23    [75326b19] (07/340) Accurately ripped as in pressing(s) #8
24    [32293bfc] (06/328) Accurately ripped as in pressing(s) #10
Offsetted by -1421:
01    [7700430c] (03/350) Partial match to pressing(s) #12
02    [9b0e85ab] (03/349) Partial match to pressing(s) #12
03    [796d0925] (03/352) Accurately ripped as in pressing(s) #12
04    [e119779e] (03/348) Accurately ripped as in pressing(s) #12
05    [78e7df9a] (03/353) Accurately ripped as in pressing(s) #12
06    [5150b641] (03/350) Partial match to pressing(s) #12
07    [7a069032] (03/346) Accurately ripped as in pressing(s) #12
08    [c38d9244] (03/352) Accurately ripped as in pressing(s) #12
09    [ce59b738] (03/352) Accurately ripped as in pressing(s) #12
10    [e540a9b7] (03/353) Partial match to pressing(s) #12
11    [38ed3dcb] (03/351) Partial match to pressing(s) #12
12    [e8a1f2d4] (03/351) Accurately ripped as in pressing(s) #12
13    [68e76886] (03/352) Accurately ripped as in pressing(s) #12
14    [66a22799] (03/351) Accurately ripped as in pressing(s) #12
15    [0625e200] (03/347) Accurately ripped as in pressing(s) #12
16    [43ff0f99] (03/342) Accurately ripped as in pressing(s) #12
17    [a6713e86] (03/346) Accurately ripped as in pressing(s) #13
18    [d34ce712] (03/351) Accurately ripped as in pressing(s) #12
19    [603c8cb8] (03/347) Partial match to pressing(s) #12
20    [c3f42ff6] (03/349) Partial match to pressing(s) #12
21    [3ad8bf82] (03/344) Partial match to pressing(s) #12
22    [b411e06d] (03/343) Accurately ripped as in pressing(s) #12
23    [ef344d99] (02/340) Accurately ripped as in pressing(s) #12
24    [1c2373af] (02/328) Accurately ripped as in pressing(s) #14
Offsetted by -1267:
01    [2544f780] (57/350) Partial match to pressing(s) #3
02    [36d860db] (57/349) Partial match to pressing(s) #3
03    [37403730] (58/352) Accurately ripped as in pressing(s) #3
04    [5db4f67b] (57/348) Accurately ripped as in pressing(s) #3
05    [a7ff57d3] (57/353) Accurately ripped as in pressing(s) #3
06    [5a056abb] (57/350) Partial match to pressing(s) #3
07    [1b3bb2fb] (56/346) Accurately ripped as in pressing(s) #3
08    [54be7c94] (58/352) Accurately ripped as in pressing(s) #3
09    [b40549ba] (58/352) Accurately ripped as in pressing(s) #3
10    [f50fa7a1] (57/353) Partial match to pressing(s) #3
11    [a7447b3d] (58/351) Partial match to pressing(s) #3
12    [cb4fb9c6] (58/351) Accurately ripped as in pressing(s) #3
13    [04e897e5] (57/352) Accurately ripped as in pressing(s) #3
14    [d76e1bdc] (57/351) Accurately ripped as in pressing(s) #3
15    [abd17181] (57/347) Accurately ripped as in pressing(s) #3
16    [11a65a85] (54/342) Accurately ripped as in pressing(s) #3
17    [765ac4c3] (54/346) Accurately ripped as in pressing(s) #3
18    [17607cf6] (57/351) Accurately ripped as in pressing(s) #3
19    [b18cae6e] (56/347) Accurately ripped as in pressing(s) #3
20    [5ab38d5c] (56/349) Partial match to pressing(s) #3
21    [858dd6da] (56/344) Partial match to pressing(s) #3
22    [808ca234] (55/343) Accurately ripped as in pressing(s) #3
23    [48ada768] (55/340) Accurately ripped as in pressing(s) #3
24    [d0cfc45d] (52/328) Accurately ripped as in pressing(s) #3
Offsetted by -1262:
01    [c851a0b5] (39/350) Partial match to pressing(s) #4
02    [592b5af5] (39/349) Partial match to pressing(s) #4
03    [ab9307fc] (38/352) Accurately ripped as in pressing(s) #4
04    [fa1014db] (37/348) Accurately ripped as in pressing(s) #4
05    [538cf68e] (39/353) Accurately ripped as in pressing(s) #4
06    [b81f4996] (38/350) Partial match to pressing(s) #4
07    [970463a0] (37/346) Accurately ripped as in pressing(s) #4
08    [62a0bad4] (38/352) Accurately ripped as in pressing(s) #4
09    [2db457b9] (37/352) Accurately ripped as in pressing(s) #4
10    [e680fa9c] (39/353) Partial match to pressing(s) #4
11    [f482346d] (38/351) Partial match to pressing(s) #4
12    [693476df] (38/351) Accurately ripped as in pressing(s) #4
13    [5dee2163] (38/352) Accurately ripped as in pressing(s) #4
14    [a0e2ab4d] (38/351) Accurately ripped as in pressing(s) #4
15    [0c508e43] (37/347) Accurately ripped as in pressing(s) #4
16    [b4fa8927] (37/342) Accurately ripped as in pressing(s) #4
17    [d8adac03] (38/346) Accurately ripped as in pressing(s) #4
18    [ecc9bfe9] (37/351) Accurately ripped as in pressing(s) #4
19    [e93d4a26] (38/347) Accurately ripped as in pressing(s) #4
20    [c6a92457] (38/349) Partial match to pressing(s) #4
21    [07fac8a6] (38/344) Partial match to pressing(s) #4
22    [7c285b23] (37/343) Accurately ripped as in pressing(s) #4
23    [289241d6] (37/340) Accurately ripped as in pressing(s) #4
24    [97bfba4a] (36/328) Accurately ripped as in pressing(s) #4
Offsetted by -889:
01    [8d00083f] (08/350) Partial match to pressing(s) #8
02    [ace4937a] (08/349) Partial match to pressing(s) #8
03    [928b3af2] (07/352) Accurately ripped as in pressing(s) #10
04    [f834092b] (07/348) Accurately ripped as in pressing(s) #10
05    [e3fa2d58] (08/353) Accurately ripped as in pressing(s) #8
06    [d418c2fe] (08/350) Partial match to pressing(s) #8
07    [3c88a3f5] (08/346) Accurately ripped as in pressing(s) #8
08    [264a05ee] (08/352) Accurately ripped as in pressing(s) #8
09    [8bb98290] (08/352) Accurately ripped as in pressing(s) #8
10    [16bfb34b] (08/353) Partial match to pressing(s) #8
11    [09c2c598] (08/351) Partial match to pressing(s) #8
12    [5b358548] (08/351) Accurately ripped as in pressing(s) #8
13    [92ce4f06] (08/352) Accurately ripped as in pressing(s) #8
14    [8f47d827] (08/351) Accurately ripped as in pressing(s) #8
15    [0acaa3c3] (07/347) Accurately ripped as in pressing(s) #10
16    [20146d12] (08/342) Accurately ripped as in pressing(s) #8
17    [400fff9c] (07/346) Accurately ripped as in pressing(s) #10
18    [84e54b4c] (08/351) Accurately ripped as in pressing(s) #8
19    [d7a9ecd5] (08/347) Accurately ripped as in pressing(s) #8
20    [6fa089e2] (08/349) Partial match to pressing(s) #8
21    [3ced3eb2] (08/344) Partial match to pressing(s) #8
22    [7d1b3bda] (07/343) Accurately ripped as in pressing(s) #10
23    [efd4a204] (07/340) Accurately ripped as in pressing(s) #9
24    [df768157] (07/328) Accurately ripped as in pressing(s) #9
Offsetted by -664:
01    [fc94894e] (23/350) Accurately ripped as in pressing(s) #5
02    [a49a3b06] (23/349) Accurately ripped as in pressing(s) #5
03    [bb1af35b] (23/352) Accurately ripped as in pressing(s) #5
04    [c6d5bf2f] (23/348) Accurately ripped as in pressing(s) #5
05    [6c28cf7c] (23/353) Accurately ripped as in pressing(s) #5
06    [360d027f] (23/350) Accurately ripped as in pressing(s) #5
07    [c460e985] (23/346) Accurately ripped as in pressing(s) #5
08    [ddafb11b] (23/352) Accurately ripped as in pressing(s) #5
09    [3d264754] (23/352) Accurately ripped as in pressing(s) #5
10    [0e84371e] (23/353) Accurately ripped as in pressing(s) #5
11    [6c16439f] (23/351) Accurately ripped as in pressing(s) #5
12    [ac3808c3] (23/351) Accurately ripped as in pressing(s) #5
13    [b88f6dfe] (23/352) Accurately ripped as in pressing(s) #5
14    [a8d7375c] (23/351) Accurately ripped as in pressing(s) #5
15    [a4c9f84c] (23/347) Accurately ripped as in pressing(s) #5
16    [50eb2b2e] (23/342) Accurately ripped as in pressing(s) #5
17    [e502d039] (23/346) Accurately ripped as in pressing(s) #5
18    [bd73e23d] (23/351) Accurately ripped as in pressing(s) #5
19    [752ee5c9] (23/347) Accurately ripped as in pressing(s) #5
20    [69cc1401] (23/349) Accurately ripped as in pressing(s) #5
21    [2a13bf8e] (23/344) Accurately ripped as in pressing(s) #5
22    [0e689d59] (23/343) Accurately ripped as in pressing(s) #5
23    [add7fc1d] (22/340) Accurately ripped as in pressing(s) #5
24    [708afe39] (22/328) Accurately ripped as in pressing(s) #5
Offsetted by -654:
01    [4a241e34] (13/350) Accurately ripped as in pressing(s) #7
02    [49a956b6] (13/349) Accurately ripped as in pressing(s) #6
03    [43bbadea] (13/352) Accurately ripped as in pressing(s) #7
04    [1293a529] (14/348) Accurately ripped as in pressing(s) #6
05    [7f734f4d] (14/353) Accurately ripped as in pressing(s) #6
06    [ae1f7abe] (13/350) Accurately ripped as in pressing(s) #6
07    [8bfc8fd8] (13/346) Accurately ripped as in pressing(s) #6
08    [0a282a81] (13/352) Accurately ripped as in pressing(s) #7
09    [f8df2dcc] (14/352) Accurately ripped as in pressing(s) #6
10    [720dc4ec] (14/353) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fuki on 2009-07-19 22:51:29
Another question regarding AR...

Does the AR database have the actual name of the disc (Artist, Title) stored along with the Disc ID and its track CRC values?
In another words, can I find out the name of the disc if I have its Disc ID (and vice versa)?

I ask this because I have a CD by Sting (Fields of Gold) which was burned incorrectly and I ripped it with EAC and EAC submitted those wrong AR results into AR database (that was a few months ago).
Now, after I found out that it was burned incorrectly, I ripped that CD into image and wanted to use CueTools to find out the correct offset, but... guess what. AR is returning 100% match (1/1) and that is (I am positive) the one my EAC has submitted a few month agos.
So, if CouTools could give me a list of potential CD's (like FreeDB does), I could pick the right one and than CueTools can give me the AR results for that one.

Is that possible?

Best regards,
Tom
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-07-20 02:46:44
Now I guess I found a bug... opened CUEtools.exe, used D&D mode to add six .cue files... and got an error. I can't unset "Manually", as you might see...

(BTW, I guess my previous comment is pointless, I found out that the batch mode works similar...)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: waaateva on 2009-07-20 05:53:03
The problem is that if there are more than 10 offset results, CueTools display only first 10. And what if the correct offset value is within next 10 results? Is is possible to find out all possible offsets at once?

I've compiled a version of CUETools.AccurateRip.dll without the 10 offsets limit. Download it here (http://www.mediafire.com/?hhmf12o2fly).
(Replace the one in your CUETools folder. Use at your own risk!)

@Gregory: I can't see the usefulness of this limit. Could you at least make it optional?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fuki on 2009-07-20 10:54:25
The problem is that if there are more than 10 offset results, CueTools display only first 10. And what if the correct offset value is within next 10 results? Is is possible to find out all possible offsets at once?

I've compiled a version of CUETools.AccurateRip.dll without the 10 offsets limit. Download it here (http://www.mediafire.com/?hhmf12o2fly).
(Replace the one in your CUETools folder. Use at your own risk!)

@Gregory: I can't see the usefulness of this limit. Could you at least make it optional?

Tnx, but I prefer Gregory's binaries and DLLs. Don't want to have a glitch somewhere.

BTW Should I decide to use it anyway, what version is this DLL compatible with (2.0.3?) and is it for 32-bit or 64-bit version?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: waaateva on 2009-07-21 06:10:46
Works fine on my XP x86, CUETools 2.0.3.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ryker on 2009-07-21 19:58:07
Hey.  Hopefully this problem hasn't been posted already... reading through hundreds of posts just to find out does not seem fun =X

I have a rip of a CD that, when run through Accuraterip, gives me the following report:

Code: [Select]
[Disc ID: 0010513d-008297e5-780a1c0a]
Using preserved id, actual id is 00105b7a-0082e023-8e0a200a.
Track [ CRC    ] Status
 01 [556083d0] (00/09) No matches
 02 [8e0bc192] (00/09) No matches
 03 [e21b5480] (00/09) No matches
 04 [e45ba285] (00/09) No matches
 05 [9678f28a] (00/09) No matches
 06 [f8ca984e] (00/09) No matches
 07 [17c734bc] (00/09) No matches
 08 [6b56fdac] (00/09) No matches
 09 [e6da051f] (00/09) No matches
 10 [d138c590] (00/09) No matches

There's just one thing: I'm not using a preserved ID.  There is no REM ACCURATERIPID tag in the entire CUE Sheet.  So where is CUE Tools getting that "preserved ID" from?  I tried putting a tag in there with the actual ID and it will force that check, but when I remove the tag, it goes right back to checking the false ID.  Why?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-07-22 03:58:34
hello everyone... i've been a long time reader of the forums here and have gotten tons of valuable info. first, thanks to the author(s) of the wonderful CUETools, I have been looking for a piece of software like this for ages and I'm excited to have it now.

Although I have tried to read up and learn as much as possible, I am still having trouble wrapping my head around a few concepts... one of them being offsets. I have tried reading and searching through this thread, but it's simply too many pages to read through.. and my girlfriend has already been bitching at me enough to get off the computer when I start getting into these and reading them. I just need someone with a clear understanding of this to lay this out to me in a simple enough manner where I can grasp the concept.

I will give this example. These are the calculations from a 13 track CD,  file-per-track FLAC files; this is the first table under the "disc id" line. I assume this is the actual calculated CRC of the input tracks that i am verifying...? (please correct me if i'm wrong) Obviously, something isn't matching up, since there are no matches showing:

Code: [Select]
Track	[ CRC    ] Status
 01 [213508d0] (00/23) No matches
 02 [90b36db6] (00/23) No matches
 03 [1152ecdf] (00/23) No matches
 04 [6e1252ab] (00/23) No matches
 05 [d3591909] (00/23) No matches
 06 [2cf2a748] (00/23) No matches
 07 [2b7fa67c] (00/23) No matches
 08 [81453f47] (00/23) No matches
 09 [ea507b41] (00/23) No matches
 10 [3d4ba5bd] (00/23) No matches
 11 [c1f5c908] (00/23) No matches
 12 [370b551f] (00/23) No matches
 13 [40fd1bea] (00/23) No matches

I have gathered that what is wrong is the offset, because there are several more tables underneath of different "pressings" using different offsets, for instance:

Code: [Select]
Offsetted by 6:
 01 [05b7cf72] (15/23) Accurately ripped as in pressing(s) #1
 02 [829d6f3f] (15/23) Accurately ripped as in pressing(s) #1
 03 [5d639b34] (15/23) Accurately ripped as in pressing(s) #1
 04 [a6c7db40] (15/23) Accurately ripped as in pressing(s) #1
 05 [3c021a2a] (15/23) Accurately ripped as in pressing(s) #1
 06 [b77a7c94] (15/23) Accurately ripped as in pressing(s) #1
 07 [8c789ccc] (15/23) Accurately ripped as in pressing(s) #1
 08 [2ad60b8d] (15/23) Accurately ripped as in pressing(s) #1
 09 [973462dd] (15/23) Accurately ripped as in pressing(s) #1
 10 [14e882c3] (15/23) Accurately ripped as in pressing(s) #1
 11 [16bc618d] (15/23) Accurately ripped as in pressing(s) #1
 12 [51ca571e] (15/23) Accurately ripped as in pressing(s) #1
 13 [3e2ef5aa] (15/23) Accurately ripped as in pressing(s) #1

I see that my tracks with an offset of 6 applied, matches pressing #1. I realize that if I select my files, choose Encode or Encode and Verify and put in 6 as a manual offset, then after encoding, my tracks will match up and then BAM, all is good... the FLAC files test out in both CUETools and TripleF.

I am assuming that I have modified the data in the FLAC files and maybe.. shifted the samples over +6 or something? I am trying to understand:

1) To me it seems that in a file-per-track rip, if i change the offset by so much, I am effectively either cutting "X" amount of audio off of the end of track or the beginning of the track (depending if the offset is positive or negative)...?

2) Am I going about this the wrong way by re-encoding?

3) By adjusting the offsets, am I losing audio data? For instance, if there were a huge sample offset, and I change it to that, is it possible it could cut off the first or last second(s) of audio in the track?

4) If I recall correctly, if i take this "corrected" version from the Converted folder, and create a dummy CUE file for it, using a ripping program like EAC or dbPowerAmp, the disc shows up as absent from the AR database or fails. Any idea why?

5) When fixing the offset (if this is OK to do), is it best to choose the smallest offset difference (so as to limit the "difference" between the original and fixed, or is it best to fix the offset according to the pressing with the most confidence? smaller offset vs. more confidence

Ultimately, from these questions, is the main point: When I have a FLAC set with no cue or log, and it does not match AR entries because of an incorrect offset... and I fix the offset, am I removing audio or destroying the integrity of the tracks or am I doing no harm?

Thank you to anyone who can help explain!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ryker on 2009-07-23 09:53:36
One more thing: what does "Fix Encoding" do when using the Freedb lookup option?  It searches Freedb and Musicbrainz and comes up with a bunch of CD track times, start and finish.  I have a CD in which my start and finish times were different than Freedb's start and finish times for each track.  So, I checked the "Fix Encoding" box and then made a new encoding of it.  I then began a new encoding with THAT new copy to check it against Freedb again, and the exact same difference came up.  It's like it didn't do anything.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-27 15:13:26
Does the AR database have the actual name of the disc (Artist, Title) stored along with the Disc ID and its track CRC values?
In another words, can I find out the name of the disc if I have its Disc ID (and vice versa)?
So, if CouTools could give me a list of potential CD's (like FreeDB does), I could pick the right one and than CueTools can give me the AR results for that one.

Unfortunately, AR database doesn't have the actual name of the disc, and doesn't provide any search interface.
In theory one might use freedb to locate the possible discids by artist/title. But that would not be of much help.
DiscId is only a function of track lengths. If your CD-R copy has different track lengths from the original,
there's no straightforward way to compare the tracks.

There is one simple case when freedb can help, that is if original CD had a non-zero pregap, and that is the only difference between it and your backup copy.
When locating this disc in freedb (e.g. using CUETools itself), one of the results will most probably contain a correct pregap value, which you can then specify in CUETools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-27 15:17:51
There's just one thing: I'm not using a preserved ID.  There is no REM ACCURATERIPID tag in the entire CUE Sheet.  So where is CUE Tools getting that "preserved ID" from?  I tried putting a tag in there with the actual ID and it will force that check, but when I remove the tag, it goes right back to checking the false ID.  Why?

ACCURATERIPID is probably present as a tag in audiofiles.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-27 15:51:10
Although I have tried to read up and learn as much as possible, I am still having trouble wrapping my head around a few concepts... one of them being offsets. I have tried reading and searching through this thread, but it's simply too many pages to read through.. and my girlfriend has already been bitching at me enough to get off the computer when I start getting into these and reading them. I just need someone with a clear understanding of this to lay this out to me in a simple enough manner where I can grasp the concept.


You answered most of the questions yourself.

Here is the closest analogy i can think of: Non-offset-corrected rip would be a copy of the book, where e.g. the first several pages of the book are missing, and the same number of blank pages is inserted in the end, so that the total amount remains the same.

Offset correction would insert several blank pages at the beginning, and remove the same number of pages at the end. (or vise versa, if offset is negative)

If this is the same number of pages that was lost when ripping, than the correction is harmless. No additional pages will be lost.

This can only be achieved when you know exactly which drive model was used during initial ripping, lookup this drive's offset at http://www.accuraterip.com/driveoffsets.htm (http://www.accuraterip.com/driveoffsets.htm), and apply this offset.

Any automatic offset correction (to the nearest or to the most popular offset) is risky - it can result in additional pages being lost. Correction to the nearest offset is statistically less harmful.

I already stated my opinion several times, that there's no good reason to correct offsets - some data can be lost, and nothing can be gained (unless you intend to burn the result to CD-R and want it to be identical to some pressing of the original CD)

The good news is that in most cases those first/last 'pages' are blank anyway, and the most you can loose is about 4 milliseconds of near-silent audio.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-27 15:57:09
One more thing: what does "Fix Encoding" do when using the Freedb lookup option?  It searches Freedb and Musicbrainz and comes up with a bunch of CD track times, start and finish.  I have a CD in which my start and finish times were different than Freedb's start and finish times for each track.  So, I checked the "Fix Encoding" box and then made a new encoding of it.  I then began a new encoding with THAT new copy to check it against Freedb again, and the exact same difference came up.  It's like it didn't do anything.

"Fix encoding" has nothing to do with track lengths, it fixes track names for entries that were submitted using non-unicode software, such as EAC, when track names are in non-latin (e.g. cyrillic) encoding.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-27 15:57:57
@Gregory: I can't see the usefulness of this limit. Could you at least make it optional?

I guess it makes sense.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-07-27 16:04:55
Feature request:
A job queue, so CUETools can process another file while displaying the log for a finished one.
(And I could set a few jobs and leave it alone for a while.)

Sounds very nice. I don't think i can do it soon, but i'll keep that in mind.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ryker on 2009-07-28 12:27:59
Thanks a lot for the answers!  I wasn't even aware that audio files could have ACCURATERIPID tags in them.

Your program is great.  Keep it up!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rootsandculture on 2009-08-01 05:43:47
I want to know if Windows 2000 is supported by CueTools, since Version 2.0.x i get an .net framework error "Unable to find an entry point named "ILFree" in DLL 'shell32.dll'  : Continue or quit

If I hit continue, program starts, but in left panel, there is no browser, and it remains "freezed".

Any ideas?
Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-01 07:23:37
I want to know if Windows 2000 is supported by CueTools, since Version 2.0.x i get an .net framework error "Unable to find an entry point named "ILFree" in DLL 'shell32.dll'  : Continue or quit

If I hit continue, program starts, but in left panel, there is no browser, and it remains "freezed".

Any ideas?
Thanks


My quick advice:

If there seems to be a problem with a corrupt .NET framework, i would recommend this tool, developed by someone affiliated with Microsoft/MSDN. Do a google search for the file "netfx_setupverifier_new.zip" and look for the  Aaron Stebner WebLog. You can run this utility, which you select which version of the .NET framework you want to verify/test, and then it will check and see if there are any problems with the installation, such as missing/corrupt files or screwed up registry entries, etc.  If you find problems, or otherwise want to start over fresh, I would try removing the .NET framework from Add/Remove programs, then (on either success or failure) running this tool by the same author... which manually cleans any traces left of the .NET framework version you select. Again, google search for the filename "dotnetfx_cleanup_tool.zip" on Aaron Stebner's site. There are plenty of instructions and info on the page; plus the programs are extremely straightforward.

From quick lookup, it appears to me that the latest version that runs on 2000 is .NET framework 2.0 SP1... which requires that you be at Service Pack 4. (Unverified that this is the last version that works with Windows 2000, I could be wrong, but microsoft's site stops mentioning Windows 2000 in the list at this point).

That should get you pointed in the right direction if it is indeed a .NET problem.. but 2000? Thought about upgrading?

Anyways, I hope that advice helped you in some way. Let me know the results out of curiosity.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-01 18:37:08
That's not a .NET problem.

Win2k is not officially supported, but it might work with recent service pack and
most importantly - recent Internet Explorer version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rootsandculture on 2009-08-01 19:03:20
That's not a .NET problem.

Win2k is not officially supported, but it might work with recent service pack and
most importantly - recent Internet Explorer version.


Lastest Service Pack is SP4 and update Rollup installed.
Lastest IE is 6SP1

I tried installing NET Framework 2.0 SP1, with no luck
When hide the browser (the left panel), rest appears to be ok.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-03 13:43:11
Well, your system is up to date, as far as i know IE6 is the maximum version for Win2k.
Which means, that the browser panel won't work on Win2k. Sorry.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-06 14:29:36
Another experimental version is out.
Not much new there again this time, summer makes me lazy.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-06 14:34:36
Another experimental version is out.
Not much new there again this time, summer makes me lazy.


awesome... thanks for all your hard work!! great program, i'm glad to see that you're still putting time into it. it's much appreciated!



edit: just FYI, i'm having some trouble with the new version... getting a few errors such as (Could not load file or assembly 'CUETools.Codecs.TTA, Version=1.0.3505.28501, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1). --- this is when selecting a flac group in multi-select mode

the dll file is there... maybe it is trying to look in the current directory of the FLAC files instead of EXE location? or maybe DLL extention was accidentally left off? sorry.. no programmer, just trying to help


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-06 15:02:02
Is your system 32-bit or 64? If 32, maybe you downloaded x64 version by mistake?
Does it verify/encode FLACs after showing this error message?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: frozenspeed on 2009-08-06 15:57:06
This is a longshot but ever thought of integrating support for discogs.com in there?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-08-06 18:34:10
v2.0.4 says "Welcome to CUETools 2.0.3".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-06 22:47:47
Sorry, but things are getting worser & worser for me, I already never used V2.03, but I cannot even test V2.04 as the drag&drop zone has completely disapeared ... & I am not even using 120% fonts this time.

Windows XP SP2 (Net Framework V2.0+Ms Visual C++) Font Size=100% (Default):

(http://img197.imageshack.us/img197/106/clipboard01xfv.png)

Things get even worst when I select the convert mode:

(http://img197.imageshack.us/img197/2999/clipboard02p.png)

I am still using V2.02, & it was not a big problem with V2.03 but there are added features/fix in V2.04 that I would like to adopt now, specially [* AccurateRip log made a bit more tidy (good offsets first, no 'as in pressing(s)' spam] which is a fix I requested ... I hope this will get fixed.

Am I alone to have this problem ? I mean, my settings are very basic now, I turned every display tunings off in order to, at last, try this version, even with bugs like I did with V2.03, but this time I completely failed ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-07 02:41:20
just to give you a little more info... i am running Windows XP SP3 (32-bit), and I am positive I downloaded the x86 version (the folder name has x86 in it, plus i re-downloaded and tried extracting/running it from a different drive).

Any other info I can give you... as for .NET version installed, I have

.NET Framework 1.1
.NET Framework 2.0 SP2
.NET Framework 3.0 SP2
.NET Framework 3.5 SP1

The error occurs in all modes when doing a VERIFY, and it opens the bottom log window, then immediately spits out the error and goes no further. This is the only output shown in the output window. It does not totally crash the program, it just will not verify files. Here is the code shown, and a screen shot of (possibly the same) error code in a dialog box.

C:\FLAC\01 - Whatever.flac: Could not load file or assembly 'CUETools.Codecs.TTA, Version=1.0.3505.28501, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1).

(http://i46.photobucket.com/albums/f132/poisonfortheweak/2009-08-06205900-1.jpg)

Hope this helps in finding the problem.

BTW, I ran the program in a virtual machine and I came up with the same error... and on my girlfriend's laptop.. same thing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-07 03:47:04
Chinch:
Do you have Microsoft Visual C++ (http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en) installed ? I get this kind of error message if I don't install it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-07 05:04:53
Chinch:
Do you have Microsoft Visual C++ (http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en) installed ? I get this kind of error message if I don't install it.


yes, it looks like i have both 2005 and 2008 versions. not sure what program(s) installed each version, but i know the ATL updates came down from windows update recently it seems... here is a shot of it:

(http://i46.photobucket.com/albums/f132/poisonfortheweak/visualc.jpg)

still a mystery to me. i noticed my g/f's laptop, which has the same error message.. has only the 2005 version... but also that update. maybe i'll try and remove the update and see what happens...

is ANYONE else experiencing this problem? i have tested it out on 3 different machines and got the same result.. that can't be coincidence...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bovinethrower on 2009-08-07 05:20:44
I've been using the old Moitah CUE Tools v1.9.1 for a while, but I decided to try the new version. Unfortunately, I keep getting "Exception: There are no more files." I would love to use all the new features, but it just doesn't want to work for me.

I'm currently running CUE Tools x86 in Windows XP as a guest in VirtualBox on OpenSolaris 2009.06. I'm moving to a Solaris and ZFS based file server, so I'm in the transition phase of moving data. I decided to split my old FLAC images to individual tracks with CUE Tools while I'm taking the time to organize everything.

I think the problem is that I have my ZFS backup drive as a shared folder in VirtualBox and mounted in XP (just like you would mount a standard network folder). I thought the problem might have been the long paths I have to my music (/backup/media/audio/old/flac/%artist%/%album%/%artist%-%album%.cue in Solaris, B:\media\audio\etc... in Windows) but making shorter paths didn't work. I'm sure it has nothing to do with VirtualBox because I copied files from the shared folder to the hard drive XP is installed on (a virtual hard drive in VirtualBox) and all versions of CUE Tools worked. The odd thing is that the old v1.9.1 works fine with the shared folder.

So, I'm wondering if anybody has tried running CUE Tools on files in a mounted network folder. It seems that the current version of CUE Tools has problems with files on mounted network drives / folders.

I hope this gets fixed soon, otherwise I'll be using the old version on the 200+ albums I have to convert.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2009-08-07 06:23:21
My friend told me yesterday that new version 2.0.4 were out. I worked with 2.03 but I got no info from the built-in update. Should that be because of the experimental version?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-07 06:27:36
My friend told me yesterday that new version 2.0.4 were out. I worked with 2.03 but I got no info from the built-in update. Should that be because of the experimental version?


mine shows it in the main log window when i start up 2.0.3.. it says 2.0.4 is out! but it wasn't a popup box or anything.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2009-08-07 09:43:12
The field on the left (where earlier the file browser was) is really thin and the main program window doesn't let to make itself brighter.

I updated 2.3a to 2.04 at home without problems - just deleted all files in program folder and unzipped the new ones.
As I did the same at work I became first an error, by the second try the program started with just 1 profile listed.
After that I deleted all old settings files and now it works fine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-08-07 10:05:06
First time I started the new 2.0.4 version I got an unexpected error in .net framework:



Code: [Select]
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
  at JDP.frmCUETools.set_FileBrowserState(FileBrowserStateEnum value)
  at JDP.frmCUETools.LoadSettings()
  at JDP.frmCUETools.frmCUETools_Load(Object sender, EventArgs e)
  at System.Windows.Forms.Form.OnLoad(EventArgs e)
  at System.Windows.Forms.Form.OnCreateControl()
  at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
  at System.Windows.Forms.Control.CreateControl()
  at System.Windows.Forms.Control.WmShowWindow(Message& m)
  at System.Windows.Forms.Control.WndProc(Message& m)
  at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
  at System.Windows.Forms.ContainerControl.WndProc(Message& m)
  at System.Windows.Forms.Form.WmShowWindow(Message& m)
  at System.Windows.Forms.Form.WndProc(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
CUETools
Assembly Version: 2.0.3.1
Win32 Version: 2.0.3.1
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.exe
----------------------------------------
CUETools.Processor
Assembly Version: 1.9.4.0
Win32 Version: 1.9.4.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.Processor.DLL
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
CUEControls
Assembly Version: 1.0.3469.35476
Win32 Version: 1.0.0.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUEControls.DLL
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

After quiting and restarting cuetools it gave no error (started complete with dropzone). Working with 32-bit XP service pack 3.

Also since I started it I have some problems:
* notepad doesn't start
* word doesn't start
* totalcommander stopped working
Don't know if it all relates to the unexpected error, but had no problems before starting cuetools.


update:
I opened cuetools on another pc without servicepack3. There it starts without a problem, but this time without a drag 'n drop zone, except a small indication where it should be (same as sauvage78).

Update2: screamed too early, I had to choose from the pull down menu 
But after dropping and a verify I got the same error as Chinch
Also in filebrowser mode I get the same error.


I like the lay-out much more than the previous one. Many thanks for all the efforts!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-07 11:07:28
Sorry, but things are getting worser & worser for me, I already never used V2.03, but I cannot even test V2.04 as the drag&drop zone has completely disapeared ... & I am not even using 120% fonts this time.

Windows XP SP2 (Net Framework V2.0+Ms Visual C++) Font Size=100% (Default):


I think i found the source of your problems.
Tried it out on freshly installed XP, and got the same picture.
Problem dissapeared after i updated the .NET framework: http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f&displaylang=en)
Microsoft also recommends this update (http://www.microsoft.com/downloads/details.aspx?familyid=6c095bba-6100-4ec9-9c54-6450b0212565&amp;displaylang=en&displaylang=en).

Thanks everyone for your reports, i'm currently investigating them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-07 12:41:08
C:\FLAC\01 - Whatever.flac: Could not load file or assembly 'CUETools.Codecs.TTA, Version=1.0.3505.28501, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1).

Ok, i think i solved this one too. Windows Update silently updated my Visual Studio to use more recent version of VC redistributable package. You will need to download this one:

http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-08-07 14:07:26
C:\FLAC\01 - Whatever.flac: Could not load file or assembly 'CUETools.Codecs.TTA, Version=1.0.3505.28501, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1).

Ok, i think i solved this one too. Windows Update silently updated my Visual Studio to use more recent version of VC redistributable package. You will need to download this one:

http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en)

I updated my xp sp3 to .net framework 2 (seemed I only had 1.1 installed), installed the servicepack and update.
Now it opens without a problem, but still had the chinch problem.
After updating with vcresist it seems to work now, thanks very much.

Now do some testing
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-07 17:47:26
Edited: Seems to works now, thks. (The problem was .NET 2.0 only instead of .NET 2.0 SP2)

Can someone confirm that this is the normal display of V2.04, plz ? In the beginning I was searching Drag&Drop zone on the left & completely missed that the Input Box appeared on the top ... Are the lines on the left normal ? I can drag&drop to the Input Box but there used to be a drag&drop zone on the left so I am still not sure that all is ok right now.

Input Box appeared:
(http://img210.imageshack.us/img210/6475/clipboard01c.png)
Radio Buttons fixed:
(http://img210.imageshack.us/img210/9366/clipboard02t.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-07 18:43:24
I had a look to see if my bug with 120% fonts was related to .NET 2.0 SP2, it is not as I still have the bug with cuetools V2.02+.NET 2.0 SP2 ... but even if it's not in the changelog it is fixed in V2.04. I don't know what you did, & I don't know if you fixed it by mistake, but thks for fixing this one.

V2.02 120% Fonts=Bugs
(http://img411.imageshack.us/img411/583/clipboard01xgc.png)

V2.04 120% Fonts=No More Bugs
(http://img411.imageshack.us/img411/229/clipboard01a.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: juest on 2009-08-07 19:42:54
Hi,

First off, thank you so much for creating this application. I love it and all its features, but I was wondering if you could add one more feature (or create a small separate utility) that would re-check rips in the AccurateRip database based solely from the generated .accurip files. The .accurip files already have the hash and CRCs of the disc, so wouldn't it be possible to check for increased confidence levels of rips done in the past from the .accurip files? That way I could just place all of my old .accurip files in one folder, and load them all in batch and have the utility quickly check each one (and possibly generate new .accurip files with updated confidence levels) without having to re-scan the audio files.

The reason why I think this would be useful is I have about 100 or so of my rips that aren't yet cataloged in the AccurateRip database, but it would be interesting to see perhaps six months or a year from now the increased confidence levels of my rips, or which of my CDs have been added to the database by other people, without having re-scan them.

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 2009-08-07 20:33:22
First time I started the new 2.0.4 version I got an unexpected error in .net framework:
Code: [Select]
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
  at JDP.frmCUETools.set_FileBrowserState(FileBrowserStateEnum value)
  at JDP.frmCUETools.LoadSettings()
  at JDP.frmCUETools.frmCUETools_Load(Object sender, EventArgs e)
  at System.Windows.Forms.Form.OnLoad(EventArgs e)
  at System.Windows.Forms.Form.OnCreateControl()
  at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
  at System.Windows.Forms.Control.CreateControl()
  at System.Windows.Forms.Control.WmShowWindow(Message& m)
  at System.Windows.Forms.Control.WndProc(Message& m)
  at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
  at System.Windows.Forms.ContainerControl.WndProc(Message& m)
  at System.Windows.Forms.Form.WmShowWindow(Message& m)
  at System.Windows.Forms.Form.WndProc(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
CUETools
Assembly Version: 2.0.3.1
Win32 Version: 2.0.3.1
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.exe
----------------------------------------
CUETools.Processor
Assembly Version: 1.9.4.0
Win32 Version: 1.9.4.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUETools.Processor.DLL
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
CUEControls
Assembly Version: 1.0.3469.35476
Win32 Version: 1.0.0.0
CodeBase: file:///c:/Program%20Files/CueTools%202.04/CUEControls.DLL
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
I'm on Windows7 RC and I also had this the first time I started the x64 version. After restarting it seems to work fine though!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-07 23:36:16
Ok, i think i solved this one too. Windows Update silently updated my Visual Studio to use more recent version of VC redistributable package. You will need to download this one:

http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en)


yep.. good work.. that one did it, installing that version of the C++ redist.

although the first time i opened it after the install i did get a .net runtime error as mentioned by another poster... but it only happened the first run, after that it i haven't seen it again. [edit: it appears that it happens the first time you open 2.0.4 after opening an older version.. for instance, if you go back and open 2.0.3, then go open 2.0.4, you'll get the JIT error dialog again... no big deal cause nobody should be switching back and forth between versions, but just a little bit of added info]

thanks for looking into the fix!

now i can check out the new version of CUETools.


out of curiosity, what exactly was the problem... the newer version of the redist was causing the crashes, so installing that version downgraded it to a compatible version or what? just curious if it was an update that is going to try and pull down again

also one other question.. don't know how hard it would be to do this, it's been so long since i messed around with visual studio, but can't you make the bottom output window and the top portion a split/resizable pane? example... if you maximize the program and bring up a browser on the side... the border that separates the log area from the file browser/control area is fixed, it would be a nice little feature/fix if you could resize that, at least down, so you could see more of the file listing for instance, and have a smaller log area.

i realize that it cannot be resized up past a certain point, or it would interfere with/overlap the controls... is there some sort of property to allow it to only resize UP to a certain level? (just below where the controls start

just a suggestion for the future.. no biggie
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-07 23:52:22
Gregory S. Chudov:
Thks for your work, despite some minor bugs I have already adopted V2.04. Congratulations  .

I still have trouble with Cuetools reminding some of my settings & I don't really understand the upper left part of the new interface (profile), but overall I am happy with what you gave. I like the new bach log in the bottom, I like the cleaner logs & the mostly-fixed 120% fonts bug.

I thinks icons in the upper left like in V2.03 are more intuitive than the actual empty box that pops up when you use the Input/Output menus, in the beginning I was convinced that it was a display bug so I installed XP SP3, then .net 3 SP1 & then .net 3.5 just to make these icons (& the drag&drop zone) appear ... only to realize when I started testing that it was now working thought the menus ... stupid me 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-08-07 23:59:25
despite some minor bugs

Report them!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-08 00:08:17
Tuxman:
I will, but I must first get used to the new interface, it's a lot of change for a die-hard 2.02 user like me. Actually I am not sure if those are bugs or normal behaviour that I miss-understand.

For example the displaying bug with 120% fonts is gone in advanced setting, but I think that it is still there in a new form: on the main windows, the manual offset box is not usable. I must confirm this by switching to 100% fonts again but it requires a reboot. Don't worry, I didn't found anything that affects the ouput.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-08 08:09:44
i've got a question for those of you who are more knowledgable than me with offsets and pregaps, etc. i have a copy of a cd that has been bothering me for a few hours now.. it has been driving me crazy trying to figure out what is going on.. but i think i just found the answer as i started typing this.

my problem was that TripleFLAC was showing the CD as having some 100+ matches, reading a drive offset of +120 and a pre-gap of 00:02:32 (same according to log file, which is where it pulled it from). problem was.. in CUETools, it kept reporting CD not in the database and showing a (?) cd icon -- when paired with the correct log, it kept reporting lead-in was 00:00:24, with no matches.

I kept trying to figure out where in the hell 24 was coming from. I tried changing the pre-gap to 00:00:24,  00:02:00, nope. started looking around in musicbrainz for TOC's and track lengths and indexes, etc. tried to make my own cue files. got really just frustrated and confused that i couldn't get CUETools to agree and wanted to get to the bottom of it so i could understand.

Long story short, I looked in TripleFLAC and saw it said two possible lead-in's (24 & 32). suddenly it clicked. CUETools was for some reason reading the entry with a pre-gap of 00:00:24, which did not match at all, and TripleFLAC was reading both, and matching on the pre-gap of 00:00:32, giving me a perfect match.

So -- my questions are... can someone please clear this up for me, I'm still learning but very interested.

i understand that pre-gap and lead-in are the same thing. also, from what i understand.. these are measured in samples. i.e. "the lead-in/pre-gap is 32 samples"

1- what is the correlation between sectors and samples? i know what a sector is, it's an area of information on a disc... and samples are audio data.. but i can't seem to make sense of the two together... when i look up on MusicBrainz for instance and see 15323 sectors, etc...  i seem to have gathered from MusicBrainz that 2 seconds=00:02:00=150 sectors, but when referencing TOC stuff there, do i even need to worry about the sectors, or is that purely a media based thing.. that is, counting or matching on sectors only applies when reading the physical CD data, not the digital copy, correct?


2- why did TripleFLAC pick up two pre-gap possibilities, but CUETools seemed to only read/use the 24 entry and insist that the disc was not in the DB? i even removed all tags and took away the cue file so that it couldn't be reading any discid or anything pointing it to the wrong version. i thought normally these would show as different pressings, correct? or am i wrong in thinking that different offsets/pressings are the same as different pre-gaps/lead-ins? i thought they were both the same thing essentially...? just curious as to what went wrong there, because as soon as i put in a manual pre-gap of 00:00:32, CUETools matched it instantly, and it would be very helpful to know why it never picked up on the 32 difference at all, as if it didn't exist.

3- i understand that 00:02:00 is a pretty common pre-gap and that seems to translate to 150 sectors... no problem. but where does 00:02:32 come from in my example? i will assume that the write offset may have been off by 32 samples (or not set at all), which caused the extra :32 at the end of the real 2 second pre-gap. am i correct in this? (in that case, it would point to the fact that this was ripped from a COPY with a write offset problem of 32 samples, rather than an ORIGINAL disc, correct?)

i don't know though.. this confuses me further because i notice several other rips from different drives also seem to have a 00:02:32 pregap as well.. wtf. is this a common one as well? i thought the first was just an anomaly.

i'm slowly trying to learn on this.. and reading from you guys here on the forums has been a great help.. i'm getting a pretty good hold on the basic concepts i think (in the beginning i was confused as hell, i'll admit), i just want to make sure i'm correct in my thoughts.

I ran a search on the forums and the internet, but i am coming up empty handed... i know it's not directly related to this topic, so i'm sorry but hopefully nobody minds: what ever became of TripleFLAC? it's as if it never existed.. I can find no reference to it really other than here. What was the last/latest version? Is there a home page or any release place? Documentation? It surely doesn't replace CUETools, i just find it useful as a backup supplement in cases like the above. i have figured out bright green means match on all pressings, dark green means match on at least one of the pressings but not all, yellow is non-zero offset.. but what about the log and cue files? what does red higlighted log file mean, etc?


Thanks for putting up with all the questions... I hope someone would like to help me out and fill me in on these things! I have read posts here and knew of the board's existence for a long time, but it's CUETools that made me actually make an account and start learning more about all of this stuff, so thank you to Gregory and his program for this new interest!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-09 01:02:39
One more thing: what does "Fix Encoding" do when using the Freedb lookup option?  It searches Freedb and Musicbrainz and comes up with a bunch of CD track times, start and finish.  I have a CD in which my start and finish times were different than Freedb's start and finish times for each track.  So, I checked the "Fix Encoding" box and then made a new encoding of it.  I then began a new encoding with THAT new copy to check it against Freedb again, and the exact same difference came up.  It's like it didn't do anything.

"Fix encoding" has nothing to do with track lengths, it fixes track names for entries that were submitted using non-unicode software, such as EAC, when track names are in non-latin (e.g. cyrillic) encoding.


i have to admit, the wording on that option was confusing to me as well.. i thought it was the same as 'fix offset' when encoding for whatever reason (even though that wouldn't make much sense i don't think, since it is not showing accuraterip in the list)... but you may want to just change the text to read something like "fix character encoding" or something like that; an easy fix that would prevent any confusion. i suppose the problem is when people are working with audio files and see the word 'encoding', they immediately think of audio encoding, not text 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Boiled Beans on 2009-08-10 09:39:26
3- i understand that 00:02:00 is a pretty common pre-gap and that seems to translate to 150 sectors... no problem. but where does 00:02:32 come from in my example? i will assume that the write offset may have been off by 32 samples (or not set at all), which caused the extra :32 at the end of the real 2 second pre-gap. am i correct in this? (in that case, it would point to the fact that this was ripped from a COPY with a write offset problem of 32 samples, rather than an ORIGINAL disc, correct?)


I do own many original CDs with a 2.32 pregap. I notice most of them are from Universal and its subsidiaries, e.g. U2, The Police, etc...

Not sure what's the purpose of it though.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-10 13:51:43
3- i understand that 00:02:00 is a pretty common pre-gap and that seems to translate to 150 sectors... no problem. but where does 00:02:32 come from in my example? i will assume that the write offset may have been off by 32 samples (or not set at all), which caused the extra :32 at the end of the real 2 second pre-gap. am i correct in this? (in that case, it would point to the fact that this was ripped from a COPY with a write offset problem of 32 samples, rather than an ORIGINAL disc, correct?)


I do own many original CDs with a 2.32 pregap. I notice most of them are from Universal and its subsidiaries, e.g. U2, The Police, etc...

Not sure what's the purpose of it though.


really ? very interesting..... i'm glad i'm not crazy! 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: edwardar on 2009-08-11 10:11:39
Mmm, can't get that MS patch to install, it's having problems locating vcredist.msi.. which is odd because I think that file is contained within the downloaded package. I'm using XP SP3 with all updates. I'll search a bit to try to fix it, otherwise I'll roll back to an earlier cuetools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: edwardar on 2009-08-11 15:47:39
Ok, fixed it, had to uninstall the old c++ 5 runtime using Windows install clean up tool:

http://support.microsoft.com/kb/290301 (http://support.microsoft.com/kb/290301)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-12 04:16:37
Just some little requests, actually rips with confidence 1 are reported as accurate in the logs, could this be changed to something like "Unknown: Confidence level is too low" both in batch log & in text log, plz.

IMHO it would be more accurate/safer to start using the conclusion "rip accurate" only with confidence 2.

Also could the conclusion displayed in bach log (accurate or not) be added somewhere in front of the text log so that I could instantly search within text log & split my collection in two (accurate or not, well plus unkknown if you add it) after checking.

Also could there be an option to not add "Offset applied: XXX" within the text log, because I fix offset according to the most popular in the database & as I don't really care about offset this information is useless for me, specially as if I re-check my rip later & delete the old logs this information gets lost anyway in the new logs. So for people fixing offset to most popular pressing this information is useless & should be optionnal. (I actually delete it manually which is a  pain)

Thks for listening, keep the good work going.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-12 04:49:39
Just some little requests, actually rips with confidence 1 are reported as accurate in the logs, could this be changed to something like "Unknown: Confidence level is too low" both in batch log & in text log, plz.

IMHO it would be more accurate/safer to start using the conclusion "rip accurate" only with confidence 2.

Also could the conclusion displayed in bach log (accurate or not) be added somewhere in front of the text log so that I could instantly search within text log & split my collection in two (accurate or not, well plus unkknown if you add it) after checking.

Also could there be an option to not add "Offset applied: XXX" within the text log, because I fix offset according to the most popular in the database & as I don't really care about offset this information is useless for me, specially as if I re-check my rip later & delete the old logs this information gets lost anyway in the new logs. So for people fixing offset to most popular pressing this information is useless & should be optionnal. (I actually delete it manually which is a  pain)

Thks for listening, keep the good work going.


well i think there is sort of this option if you go into options and then accuraterip tab.. over on the right.. you can set the confidence level condition before you fix an offset or encode... but i don't think it's an option for simply verifying. that might be useful... maybe for 'show rip as accurate only if xx matches'... otherwise it would still show the 1 match, but as you said... show that it cannot be absolutely verified as accurate... but let me give you this to think about ---  can it ever be absolutely verified as accurate? it mainly can say you "most likely have a good match" since this many others got the same result -- which, statistically could be true..

BUT... when you're fixing an offset.. is your rip really 'accurate'? accurate is pretty much all relative unless you own the original cd, you make an exact copy of it the correct way, then you match against the DB... otherwise, by changing the offset of the samples, you're possibly destroying data if you're matching to another pressing other than the original CD physically ripped by you. so with the original CD + your drive's proper offset, you can say it is accurate... reburn it with a proper cue file.... then see if everything still matches. do a checksum on the tracks or better yet, entire CD via ultraiso or something that can MD5 hash a full CD. otherwise, unless you exact match on a zero offset one... you don't know. and you really still don't know even then, cause someone could have already fixed the offset, so it only appears it was perfect from the start. this is probably why he adds that it was corrected in the logs, for informational purposes. also, you already know this in your head that 1 match means it might not be accurate, so why do you really need to see it in the log? for others? that's mostly just telling someone else that your rip might be bad... kind of defeats the porpoise either way

not to be a deal breaker though! not trying to say it's a bad idea, but my main point i guess is unless you're ripping from your own original copy with the correct offset(s), you can't really rely on TRUE accuracy of a rip, ever i'd think... you can just prove that it's accurate give or take a certain range of samples, + or -  !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-12 05:47:59
Dear Chinch

well I disagree with you on 99% of your answer, but I don't want to fight with less experienced users ... it only leads to trouble here.

For the first part of your answer, well indeed you can never be 100% sure everything is perfect. But with confidence 1 & checking your own rip, the probability that your rip is accurate is near to nihil: you cannot say it is accurate, it has already been debated on other topics. Now the real question is: even if you are not an evil pirate, are sure 100% that the rip you made by yourself has made its way thru the accuraterip database ? the anwser is NO. There is plenty of reason why your own rip which could be the only result in the database has not made it's way thru the database (due to bad configuration, firewall, loss of internet connection ...). So it is not a problem of the 1 result in the database being your own rip or you being an evil pirate that checks illegal rips ... It is the problem that you can NEVER be 100% sure that the 1 result in the database his yours or not, even if you know you ripped this CD. So that leads to the conclusion that result with confidence 1 should be marked as UNKNOWN.

For the second part of your answer, well you should learn about offsets because offsets has nothing to do with accuracy, it is only usefull to actually find the CRC in the database ... my accurate rips with fixed offsets according to most popular in database is in NO WAY less accurate than your "so-called perfect rip" made with your the official pressing you bought yourself. On the one hand, your "so-called perfect official rip" is likely to be a very rare pressing in the database if you bought it in japan or russia ... on the other hand, my "so-called rip with destroyed data" (Note: no offense but it was funny to read) is likely to match the official pressing of rich country like europe or USA ... so let's repeat after me: "offset has nothing to do with audio-quality"  The second part of your answer is completly wrong according to me.

Edit: RE-reading your post, I think I understund a part of your miss-understanding: silent samples is not used in accuraterip CRC calculation, so shifting the data with offsets doesn't affect the data CRC. The so called "destroyed data" is zero bit silence ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-12 07:56:34
Another annoying behavior I noticed: for example I have my own profile set as "encode+fix offset" if I go to advanced setting & then exit advanced setting it automatically reverts back to "encode+default" ... due to this behaviour I was forced to encode twice as I didn't notice it the first time ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-12 08:05:25
fair is fair, and i'm not here to argue either. i don't think starting your post off with a personal insult was that tasteful, but i will try to explain the detail of why i disagree, and maybe you or the others can correct me, if i am indeed wrong.. and i don't claim to know it all, so that is possible.

Quote
are sure 100% that the rip you made by yourself has made its way thru the accuraterip database ? the anwser is NO.

no, i cannot be sure once it leaves my computer what happens with it. i do know that i manually submit my accuraterip results on a regular basis, and the submissions report to be successful.

Quote
There is plenty of reason why your own rip which could be the only result in the database has not made it's way thru the database (due to bad configuration, firewall, loss of internet connection ...). So it is not a problem of the 1 result in the database being your own rip or you being an evil pirate that checks illegal rips ...  It is the problem that you can NEVER be 100% sure that the 1 result in the database his yours or not, even if you know you ripped this CD.

this part doesn't make sense to me, i'm afraid. looking past the second or third insult, what you seem to be saying is that there is no reason to know whether an accuraterip submission/match of 1 is my own entry, or "evil pirate's" entry. aside from who it is ripping a CD, an accuraterip result is an accuraterip result. If I take my CD, put it in the drive, rip it.. and get a match of 1 (say it's dirty pirate's!)... regardless of who or what they are, their CD ripped with the same result as mine. I don't understand what that has to do with anything. how do i know it's not my own rip? well... usually i only rip my CD's once, unless there is a need to re-rip one... so I don't think EAC or dbPowerAmp is going to submit my results in real-time and check them against itself.

besides, i thought that the accuraterip DB had a mechanism that prevented multiple submissions from the same machine? if not, why is there a field in the accuraterip submission page called "computer identification"?

reference:

(http://www.carltonbale.com/projects/cd_audio_extraction/submit_results.png)

i could be wrong... someone who knows for sure like spoon might could say.

Quote
For the second part of your answer, well you should learn about offsets because offsets has nothing to do with accuracy, it is only usefull to actually find the CRC in the database ... my accurate rips with fixed offsets according to most popular in database is in NO WAY less accurate than your "so-called perfect rip" made with your the official pressing you bought yourself.


so if i understand you, you are saying that if i rip a CD... and it is indeed a correct rip (for this example)... and it does not match any in the DB. most popular one we'll say is -612. you take your rip, and correct the offset, that is, shift the offset of your ripped track(s) by -612... that does not change the 'accuracy' of your rip (given if is simply a different pressing that is not in the database yet)? also given those samples are not null samples.

for instance, I have a gapless track... it goes from track 2 to 3 with no gap, a seamless transition. you shift your samples by -612... you don't lose any audio data at all?

in other words, changing the offset of a correct rip to match the offset of an alternate pressing, simply to match it will never cause a loss of audio? if this is true, then i completely misunderstand the whole thing. the only way i could see this is if a certain range at the beginning and end of a track are not considered into a calculation of CRC or the data that was removed/padded were null samples. can anyone verify or deny this? this would allow for minor variances in submissions to still match. (and by minor i mean fractions of a second).

i'm just letting you know how i see things and my understanding/viewpoint of how it works. if i am wrong, then i am wrong... i'm here to learn and discuss, not to fight.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-12 08:34:11
Well your new post make much more sense to me, indeed if you go to the shop buy a CD, go home & rip it with eac or dbpoweramp, submit & get an accuracy 1 result then yes your rip is perfect. But only because you know your result & the one in the database are differents.

But IMHO you're off-topic, I am not discussing accuracy 1 in the context of EAC & DBpoweramp, but in the context of Cuetools & Cuetools is not yet a ripper.

I can have bought a CD legally, then ripped it legally without saving a log & don't recall if I submitted or not. It happened to me because in the first day of Accuraterip the database was not populated & I was not sure if I would ever use it, even if I tested it. I honestly don't recall what I ripped in these days. For these rips cuetools results with accuracy 1 are a problem for me as my ID has changed. Furthermore, experience have proved me that accuraterip database is moving ... your submission can be dropped, it happened recently for virtual drives.

Cuetools is a software, it thinks like a machine. You think like human, from your human point of view, you KNOW that your rip is perfect, because you did it & you know the submission in the database is not yours.

What does Cuetools knows about all that ? nothing. That is why I am asking for it to behave in the most basic way & report rips with accuracy 1 as Unknown. Then you're free to think that this Unknown result is safe or not.

I understand that Cuetools reports rips with accuracy 1 as accurate because it aligns itself on EAC & dbpoweramp, but what is always right in the context of EAC & dbpoweramp is not always right in the context of cuetools. Anyway even with EAC & dbpoweramp I think accuracy 1 should be treated as a special case & reported as unknown because it will help newbies understand the slight difference between accuracy 1 & accuracy 2. Reporting accuracy 1 as Unknown is good for educational purpose IMHO.

So, the question is would there be any drawback in reporting accuracy 1 as Unknown in cuetools & even in EAC & dbpoweramp. The answer as far as I know is no.

As for the second part if you would be right & if offset would break gaplessness, then the CRC would not be the same anymore because gapless means data, not silence. I understand your point better on the first part, but I think your wrong on the second part. If you were right I would have f#cked all my rips, don't give me nightmares

Edit: I think it has to do with offsets being way to small to affect any samples were songs are cutted, but I don't recall exactly. Sorry if you ever felt insulted, your questions are not stupid, I asked these questions to myself a few years ago ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-12 10:37:42
Another weird request, sorry

Would it be possible to have an option to hide the complete path in the bach log & only display the final folder name+final .cue filename, because I use my 22' LCD screen in portrait mode instead of landscape & actually 1050px is not large enough to display the complete path, I am always forced to browse my mouse to the right & it is annoying ... it will help people will lower resolution too I think.

Much sorry for annoying you with my 120% fonts in the past & now with my portrait display mode

Here is a small screenshot:
(http://img263.imageshack.us/img263/9265/clipboard01ak.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-12 14:38:29
Well your new post make much more sense to me, indeed if you go to the shop buy a CD, go home & rip it with eac or dbpoweramp, submit & get an accuracy 1 result then yes your rip is perfect. But only because you know your result & the one in the database are differents.

But IMHO you're off-topic, I am not discussing accuracy 1 in the context of EAC & DBpoweramp, but in the context of Cuetools & Cuetools is not yet a ripper.

I can have bought a CD legally, then ripped it legally without saving a log & don't recall if I submitted or not. It happened to me because in the first day of Accuraterip the database was not populated & I was not sure if I would ever use it, even if I tested it. I honestly don't recall what I ripped in these days. For these rips cuetools results with accuracy 1 are a problem for me as my ID has changed. Furthermore, experience have proved me that accuraterip database is moving ... your submission can be dropped, it happened recently for virtual drives.

Cuetools is a software, it thinks like a machine. You think like human, from your human point of view, you KNOW that your rip is perfect, because you did it & you know the submission in the database is not yours.

What does Cuetools knows about all that ? nothing. That is why I am asking for it to behave in the most basic way & report rips with accuracy 1 as Unknown. Then you're free to think that this Unknown result is safe or not.

I understand that Cuetools reports rips with accuracy 1 as accurate because it aligns itself on EAC & dbpoweramp, but what is always right in the context of EAC & dbpoweramp is not always right in the context of cuetools. Anyway even with EAC & dbpoweramp I think accuracy 1 should be treated as a special case & reported as unknown because it will help newbies understand the slight difference between accuracy 1 & accuracy 2. Reporting accuracy 1 as Unknown is good for educational purpose IMHO.

So, the question is would there be any drawback in reporting accuracy 1 as Unknown in cuetools & even in EAC & dbpoweramp. The answer as far as I know is no.

As for the second part if you would be right & if offset would break gaplessness, then the CRC would not be the same anymore because gapless means data, not silence. I understand your point better on the first part, but I think your wrong on the second part. If you were right I would have f#cked all my rips, don't give me nightmares 

Edit: I think it has to do with offsets being way to small to affect any samples were songs are cutted, but I don't recall exactly. Sorry if you ever felt insulted, your questions are not stupid, I asked these questions to myself a few years ago ...


well.. i suppose here is where we can meet an agreement.. as you made a good point in that CUETools is (as of now) a rip checker, and not a CD ripper, therefore you are checking the database after the fact, so i do understand your point here.

and yes, i do agree that for the most part, it seems that offset correcting is relatively harmless, as you said... since i most cases the part being removed or padded is indeed silence (or more specifically, null samples), not to mention fractions of a second as i was saying earlier... so it's not likely to matter in the 'real world' anyways i suppose. you're always going to have disagreements on this board, because there are at minimum two classes of listeners... those who are happy with their audio rips being "good enough" and those obsessed with "perfection" in ripping. otherwise this board would not be so lively with so many questions and debates over the years. it keeps the brain exercised, for sure.

so i'm thinking this.... if you apply padding to the beginning of a rip, it is going to be null samples... no audio.. which will then match the CRC. no problem. the tracks will ultimately be identical if the other one has silence as well. same with the other way... if you remove samples... as long as they're null, you're not leaving out any data.

but this brings up a new question that i never thought of before... when it reports alternative offset matches... are those offsets based on that cd as a whole, or individual track? the importance of that is the question "is it only the very beginning of the cd that is off by +000 samples or -000 samples, or every track?" my thought would be it is based on a full CD, since therefore in theory, you can pad or remove samples from only the first track... affecting only that one, or do you apply that offset to every track? if it were track based, then i could see it being a problem, since a lot of cd's these days don't have a two second gap between songs, they're gapless a lot of times... that's the scenario that would present a situation where the opportunity for loss of real audio samples is very viable.

i need to go back and hit the books on offsets, cause you have me questioning myself now... but questions are good, they lead to knowledge, as long as the information you are getting is correct. this is why i try to rely on people who have done things like coding of ripping programs, examination/comparison/experimentation with waveforms under different circumstances... as it is always possible to get misinformation or misunderstand things.. that goes for both of us. so i guess we can just hopefully agree that neither of us are true experts on the matter, and we can leave it at that, as we both have brought up valid and important points on the matter; and i accept your apology on the matter, as i apologize if i have offended you in any way either.

could anyone who really really knows their stuff (like a developer, etc) clear up a couple of those questions we have brought up and explain which statements we have made are correct or incorrect?



By the way... regarding your most recent post about the log area , sauvage, I think I can finally agree with you without debate on this one... I agree with you about the log. Personally, I preferred it on the left side instead of the bottom... takes up less of a footprint that way.. the new interface is cool, don't get me wrong... but could you maybe implement an option to show the log file on either the left OR bottom? and I agree with sauvage, maybe only show the .cue file name instead of the full path, as this is rather unimportant and adds a whole lot of horizontal scrolling that's not really necessary, especially for people with a lot of nested folders.. that string can get pretty long  the problem with showing only the last FOLDER is for the people who have it organized as \Artist\Album instead of just \Arist-Album or whatever.. it could possibly be more of a headache to write the code to determine which of the folders should be included or discarded than it would be just to show the cue file. in your example though, the name is generic, you would have to rename the original rip file to include the artist/album/year. This is personally how I do it, i output the WAV as Artist-Album-Year.wav    -- but it's all personal preference.

gregory, what about maybe some sort of tabbed thing for the diff modes, so you can just select the tab for which mode you want really quick to switch back and forth.. that might be quickest and most intuitive? just all suggestions and seeds for design thoughts, i think you're doing a great job on the program. already looking forward to the next update.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-12 16:43:43
well an option to chose the deepness of the path // displayed would make everybody agree

artist/year/album/CDImage.cue would gave

0=full path
1=CDImage.cue
2=album/CDImage.cue
3=year/album/CDImage.cue & so on ...

Edit:
quote: Myself post N°577 "affect any samples were songs are cutted" ==> "samples" should be read as "frame", cue sheets are cut by frame not sample, (the offset is given in samples, 1second=75frames, 1frame=588 samples)... I cannot edit my own post. It seems there is a time limit for edition now ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-08-12 18:42:47
I thing that the program should be as simple and straightforward as can be and still preform the necessary functions. If all the options are included in the basic program to satisfy everyone's quirks, the program will become too complicated for the average user.

As for the layout of the output log, everyone will never agree on one layout. If the layout has the necessary information, than leave it alone! What one person find useful, another may not, leading to never ending changes. If you know that a confidance level of 1 could be yours in some circumstances, is it really necessary that you be reminded every time that you run the program?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-12 20:41:46
I thing that the program should be as simple and straightforward as can be and still preform the necessary functions. If all the options are included in the basic program to satisfy everyone's quirks, the program will become too complicated for the average user.

As for the layout of the output log, everyone will never agree on one layout. If the layout has the necessary information, than leave it alone! What one person find useful, another may not, leading to never ending changes. If you know that a confidance level of 1 could be yours in some circumstances, is it really necessary that you be reminded every time that you run the program?


i agree with you here.. certain programs.. for instance.. ImgBurn.. when you first look at their options dialogue.. it's a little overwhelming. i admit a lot of that stuff in there i didn't even know what it meant. so i can understand that, the interface/options can become intimidating if it becomes too robust. on the other hand, the more configurable/customizable, etc a program is, that is great. i think EAC and some other programs have taken a good approach by having a 'simple' or 'beginner' mode, then an option to enable advanced user options.. that way the interface can be kept clean and simple, yet offer the advanced functionality and customization that a move advanced/hobbyist user would need to satisfy what they are trying to do.

it all depends on the programmer and how much time and effort they are willing to put into the program... i understand adding features and options takes time to code up, and you are indeed correct... not everyone is going to be satisfied with everything all the time.

given that...... as far as logs go, etc.. in the end, they're just plain text files, and if it comes down to it, you can always edit them, remove the path, remove the offset, make whatever modifications you want to suit your needs. it's a bit more work, but at least it's *possible* to get it in "x" format.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-08-12 21:34:58
From the above highly entertaining chat  , I would like to repeat the question of Chinch, because it's a question which lingered in my mind also:

Quote
for instance, I have a gapless track... it goes from track 2 to 3 with no gap, a seamless transition. you shift your samples by -612... you don't lose any audio data at all?


In other words: If an offset is applied do I lose only the samples from the first track and are all other samples moved from the subsequent track.
Or do I lose samples from all tracks?

I don't apply offset very often, but it would be nice to know what happens if I applied it to p.e. a "Live" recording.

After using 2.0.4 for a while now, I must say I like it a lot with the drag'n dropzone (or filebrowser) on the left and a resultwindow at the bottom.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-13 03:09:14
I would have to dig in old threads to find the exact answer, but offset is applied to all data. You can usually only lose real non silence samples on the last track if the drive offset is insane, that's why accuraterip ignore the last ignores last 2940 samples. If I am correct, even first track is usually safe from huge negative offset because there is almost always silence in the beginning. As for gaps, I don't recall why, I think I tested myself on a gapless Alice In Chains CD if I recall well ... gaps were not affected. This is not a scientific answer but that's what I recall from previous discussions. Anyway no sample can be lost by shifting data, even if gaps were affected, data would be shifted & not destroyed (except on last track indeed).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-08-14 12:14:14
Hi, I'm using the stable version of CUETools (1.9.5) and I would like to know: does this program correct the offsets by default if it find the corrected value via AccurateRip?
In other words, I've got this log, are the files generated corrected?
Code: [Select]
[Verification date: 14/08/2009 13.04.59]
[Disc ID: 001491a5-00d42732-9b0b0a0d]
Track    [ CRC    ] Status
01    [227cc5b1] (00/08) No matches
02    [7aa2afe3] (00/07) No matches
03    [d9678ca5] (00/07) No matches
04    [7a66fd12] (00/07) No matches
05    [46d14a8a] (00/06) No matches
06    [4bd71e44] (00/07) No matches
07    [6a3638d9] (00/07) No matches
08    [40a4d6cc] (00/07) No matches
09    [287e3303] (00/07) No matches
10    [7e027f0e] (00/07) No matches
11    [03734de5] (00/07) No matches
12    [4079e0f2] (00/07) No matches
13    [5863eb0b] (00/07) No matches
Offsetted by 48:
01    [58181c12] (08/08) Accurately ripped as in pressing(s) #1
02    [f72940f5] (07/07) Accurately ripped as in pressing(s) #1
03    [dac12a18] (07/07) Accurately ripped as in pressing(s) #1
04    [763bf9ba] (07/07) Accurately ripped as in pressing(s) #1
05    [90f62ee8] (06/06) Accurately ripped as in pressing(s) #1
06    [da6441db] (07/07) Accurately ripped as in pressing(s) #1
07    [bd8c400d] (07/07) Accurately ripped as in pressing(s) #1
08    [d3ef6460] (07/07) Accurately ripped as in pressing(s) #1
09    [a6dd0315] (07/07) Accurately ripped as in pressing(s) #1
10    [02b7f27b] (07/07) Accurately ripped as in pressing(s) #1
11    [ab7d547f] (07/07) Accurately ripped as in pressing(s) #1
12    [5d1f9351] (07/07) Accurately ripped as in pressing(s) #1
13    [ad0de8c4] (07/07) Accurately ripped as in pressing(s) #1
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-14 12:39:35
Your rip is accurate but either:
1- you have a pressing different from the one in the database & your CD pressing is +48 samples OR
2- you didn't set any offset correction when ripping & your drive's offset is -48 samples OR
3- you set a wrong offset correction & now it's something in between & you can correct your mistake by adding +48 samples.

There is no absolute correct offset, correct offset is related to a particular physical drive & a particular physical CD. Cuetools can only tell you if an offset for a CD is popular or not compared to yours. It doesn't affect quality.

PS: You should upgrade to lastest version IMHO.

Edit: 1- mixed + & -48 samples
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-08-14 12:46:02
Hmm, I don't understand what's the hubbub with the correct offset thing; can somebody tell me shortly why I would want to correct offsets if I find an album which has no AR matches, but other offsets have? Up until now I was under the impression that it is utterly pointless (and possibly harming) to go through with this procedure.

P.S. The "experimental" profiles system is buggy, hopefully I've time to test it properly and make notes this weekend.

P.P.S. Thanks a lot Gregory for the log amends!

@buddhabar: use CODEBOX tags for long listings.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-08-14 12:46:43
Thanks for the explanation, I'll try the latest version (the word "stable" had attracted me).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-14 13:02:15
Akkurat:
You can leave offset uncorrected, your rip will still be accurate. Offset have always been for paranoid people.
A rip with "No matches" with offset 0 can be perfectly accurate with offset X or Y.

But if you correct them according to the most popular in database:
1- your log will be shorter
2- popular offset are likely to be an european or USA pressing (not 100% safe)
3- you can find doublon with a dupefinder by comparing . accurip file which is faster than processing lossless files

Other than that there is no benefit & none of the above benefit is tied to quality.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-08-14 13:02:22
PS: You should upgrade to lastest version IMHO.

I don't agree, there's some bugs in the profiles system, some settings are not saved/reverted back/reverted from other profile(?), profiles management bugs, etc. problems, not yet fully tested but there are clearly bugs. More later when I have more time.. though, I'm sorry but, I wonder was it tested at all prior releasing.. I found major bugs under ~15 minutes (I don't know if it's just me.. I've learned that I've a knack for testing), I hate to test and write about "easy" bugs, I wish that those would be squashed prior releasing alpha/beta/whatever. SORRY.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-14 13:08:14
Yes there are cosmetic bugs, none is major & none affected quality for me so far. IMHO the added features overweight the minor bugs. It's a matter of taste. I already warned about easy-to-find interface bugs (particulary in the profile system & advanced setting not saving correctly). Read my previous posts.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-08-14 13:08:17
I've tried version 2.0.4 and 2.0.3 and both give me Database access error: BadRequest when I try to connect to AccurateRip database, with 1.9.5 is all fine...

EDIT: Kaspersky 2009... mpf...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-08-14 13:20:28
But if you correct them according to the most popular in database:
1- your log will be shorter

You mean the EAC log? Or what? Shorter is better because it's easier to read? Or save few KB's?

2- popular offset are likely to be the european or USA pressing (not 100% safe)

I'm sorry but what are you trying to say here? Not safe?! Can you elaborate?

3- you can find doublon, with dupe finder by comparing . accurip file which is faster than processing lossless files

I don't understand this either. Sorry. Finding a double? Is your memory so short that you can't remember which albums you have already ripped and archived? Or not being able to check your music collection if you already have the album there?

You can leave offset uncorrected, your rip will still be accurate. Offset have always been for paranoid people.
A rip with "No matches" with offset 0 can be perfectly accurate with offset X or Y.

So it is utterly pointless and possibly harming like I thought.

Still, if it's only for the paranoids/fools (sorry ), how come it was coded to CUETools? Does it serve a real purpose?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-14 13:39:25
1- no I mean the cuetools log, it will be shorter as the No matches with current offset will disappear.
2- it's a question of probability, richer country buy more CD (specially european & USA teenagers) an offset with higher popularity is likely to be a pressing from a rich country with many CD buyer (& rich enough to have a PC too) for example a Pink Floyd CD with popularity 200 is VERY unlikely an south african CD pressing ... it's only logic here. But even logic it is not 100% sure as it depends on who ripped the CD in which country ... the only thing you can say is that the higher is the offset popularity the higher it has chance to be an european or USA pressing rather than a japan or russian pressing.
3- it's usefull if you have remastered or re-release with bonus version. if you & your friend have both the same CD & you don't know for sure if it's the same master. It can be usefull when the original release wasn't a CD. For example Black Sabbath CD, there is several different version or their CDs because the original realease was a tape. I have friends with Black Sabbath CD that doesn't match mine & it's not even a remaster. Indeed you can compare audio CRC, but either you have to compare manually or you have to process big files. If you search doublon by comparing .accurip with "fixed" offset according to the most popular, it's fast & automatic.

Another use is for people like me who don't bother use offset correction when ripping but still want to automatically "fix" them without even caring about them. For exemple me: Cuetools & accuraterip are so great that they have changed the way I rip & store my CD ... I used to correct offset & rip in secure mode ... now I rip in burst mode+CRC check & verify+fix offset with cuetools ... so yes it is VERY usefull for me. It is just as safe, but it is much faster. I only use secure mode when really needed now (scratched or not in database) & I will never thks Spoon & Gregory enougth for the time saved.

As always if you don't like it, don't use it. I find it very usefull. If you think it's harming then well ... life is harmfull you know  , you shouldn't turn your PC on as HDD can die & corrup your rips.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-08-16 15:26:02
1- no I mean the cuetools log, it will be shorter as the No matches with current offset will disappear.

Ok. Fair enough, whatever pleases you. But think of how many times do you read your logs? Is it THAT important? I noticed that earlier Gregory suggested you to: "Uncheck 'Verbose' option for log files, and you will have shorter logs". Oh well, no need to answer anymore to this, each to their own.

... the only thing you can say is that the higher is the offset popularity the higher it has chance to be an european or USA pressing rather than a japan or russian pressing.

AND this has a meaning? I think this underlines the whole "fix offsets" issue here. Let's say that you've bought a Polish pressing of an album, you take measures to rip it "safe", i.e. accurately, i.e. you want to make an identical digital copy of your CD. It is reported to be accurate with another offset, i.e. pressing, using CUETools, BUT then you make a decision to fix the offset, i.e. making it NOT an identical digital copy of your CD, just because you want to have a "warm & fuzzy" feeling of having the "best" rip possible (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=624370). This logic escapes me. But it's a moot point discussing this further.. each to their own again.

3- it's usefull if you have remastered or re-release with bonus version.

But aren't those completely different albums, i.e. they do have different AR disc ID's? And thus can't be compared.

As for the rest of the reasons you wrote, most of it just doesn't make sense to me. Let's leave it a that, ok?

Another use is for people like me who don't bother use offset correction when ripping but still want to automatically "fix" them without even caring about them. For exemple me: Cuetools & accuraterip are so great that they have changed the way I rip & store my CD ... I used to correct offset & rip in secure mode ... now I rip in burst mode+CRC check & verify+fix offset with cuetools ... so yes it is VERY usefull for me. It is just as safe, but it is much faster. I only use secure mode when really needed now (scratched or not in database)

Why don't you use offset correction when ripping? Do you mean using the correct offset for your drive in EAC? I don't understand the point about secure Vs. burst mode at all, what does these have to do with the offset correction?

If you think it's harming then well

It's not what I imagine (you meant this?), it's possible.. and what I did discover, searching this topic about this, that you have been told the same thing but I see that it has gone to deaf ears.


Some quotes:

I already stated my opinion several times, that there's no good reason to correct offsets - some data can be lost, and nothing can be gained (unless you intend to burn the result to CD-R and want it to be identical to some pressing of the original CD)


This one answered my earlier question of why the fix offset function was coded to CUETools.
I personally am not very fond of the whole idea of offset correction, because to me this seems like a totally useless operation, which doesn't make a rip better. It only makes it worse by cutting some samples from the beginning or the end.
We only needed it in the past to be able to use AccurateRip, but now we can do it without offset correction.
I will continue to support offset correction in CUETools, because there are probably a lot of people with different views,
but i'm not making it a priority.


Personaly i find 'fix offset if' more and more useless.
Rip can be verified without changing offset, so there's usually no point in it.
You only loose some samples for no particular gain.
Especially in automatic mode, when it's not really predictable.
I.e. in your case the rip is perfectly alright as it is,
it makes no sense to apply an offset to make it similar to a more popular pressing.

I wanted to quote another one and make this post MEGA long , but the additional quote tags were too much for this forum software to show this post properly.. here's the link to that post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=624375).

In the end I can think of only one proper reason for using this fix offset feature: if somebody notices that some of the rips were done with no proper drive offset set in EAC and they know the correct offset of that drive. Any other reasons? Otherwise I see that this mostly pleases only music pirates..?

Edit reason: grammar.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-08-16 16:19:50
Flac encoder (don't know 'bout others 'cause don't use 'em) seems not to remember its settings and resets to default (i.e. compression=5) after restarting the program.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-16 16:58:50
acmodeu:
I had the same problem this V2.03, for me this was fixed in V2.04, plz report the version you use when you report a bug.

Akkurat:
Thks for reading back  I know the opinion of Gregory & Greynol on the topic & I agree with them on the fact that this is "useless" if you only consider that "usefull" means making your rip better. It doesn't.

So far, IMHO the supposed "risk" is just FUD (http://fr.wikipedia.org/wiki/Fear,_uncertainty_and_doubt) as no-one has proved in a scientific way that I could damage my rip by correcting offset. I recall I made my own test about gaplessness with an Alice in Chains CD & I didn't damage my gaplessness, the CRC of splitted songs with & without correcting offset was the same. I double checked the split stop/start point in audacity. Sorry I didn't post my result at time. I may be wrong & maybe my test was not enough & I ended with a special case. I don't know. In all honesty I recall I tested something but I don't recall exactly as it was several months ago. Sorry. Edit: I have alot of respect for Greynol & Gregory because both have greater knowledge than me, & even if Greynol is sometime very cold in his answers because stupid questions upset him quickly, he helped me a lot in the past. Despite all this I still think that there is no reason for an irrationnal fear of offset fixing. I agree their words have a big weight here, but it have to be seconded by real life cases. Fixing offsets is just not the recommended way of doing things & I completely agree it shouldn't be a default setting.

I didn't even thought about fixing pirate rips with no offset, one more reason for some evil people to find it usefull ... but in fact as I already explained above, I rip without correcting offset & then check with cuetools because I want a cuetools log. I only re-rip to secure when EAC tells me that the rip is not in database ... so as you see I am not the kind of guy who cares for offsets (Edit:but I do care a lot for gaplessness) ... nowadays I only care for one thing, rip the fastest way possible & get an accuraterip result of 2. In a way I rip like your evil pirates, if it has a correct offset, whatever the offset is, then nice, if it doesn't I don't care. Morality has nothing to do with offsets, I want cuetools to behave like a machine & do want I order. I don't care if pirates can abuse the setting as long as it is legal to fix offset & I find it usefull.

The discussion about this setting is interesting when it deals about if it can or not damage gaplessness as I am interested by results from other people on the matter. When it drifts on the usefullness of such an option, it is IMHO a completely useless discussion, because offsets are USELESS from the start. We use offset because drives are in a way "defective by design" & as CD is a dead format, offsets is a dead flaw. I don't intend to burn my rip, maybe you intend to burn yours, that's maybe why we have a different point of view.

Quote
But aren't those completely different albums, i.e. they do have different AR disc ID's? And thus can't be compared.

Yes, I only use it to be sure that both are different. As I said there is other ways to achive this, this one is just the fastest way I found.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-08-16 17:12:57
sauvage78, yes, everything seems to work fine now. Thanks for the hint.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Hairston on 2009-08-16 18:13:57
Greetings!

First time post and a long time user of v1.9.1 and v1.9.5 here. Lately I've had some time to check out the new version. Very nice and a big thank you to GSC for continuing development. The extra features are most welcome!

From a long time user's standpoint looking at a new version, I am mostly interested in ease of use based on my familiarity with the old version. So far it has been great!

My intial concern was why the "as in pressing(s) #x" is not available in the verbose log now.

Yes, I understand this really has no bearing on whether a track was ripped "Accurately" or not. Maybe it is truly useless information, but it is extra information about the rip that maybe some are still expecting to see.

EAC (and AccurateRip for that matter) use this nomenclature and since CUETools is inherently based on these two tools, why not use it too? It's just extra information that may or not be useful to the person using the tool, but isn't that what a verbose log is all about? I'm in agreement that it should left out of the non-verbose log so not to confuse newcomers, but that is no reason to leave it out of the verbose log. Especially when some people kinda expect to see it there.

... And yes, I have read through the older posts and understand the reasons for and against, but personally I don't see enough evidence against changing it. Especially since this is the way the app has worked from the start.

Not a deal breaker by any means, I still love the app and will continue using it. I just wanted to voice my opinion and see if anybody else agrees with me.

On a side note... GSC and Moitah, when in the future are you going to start accepting donations?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-16 18:18:10
Edit: typo
"do want I order" read "do what I order"
... the new time limit for edition is too short, I am not a native english speaker, so I correct my many mistakes several time & often add new things while correcting. It's the second time it happens to me. It will only lead me to shut my mouth ... which is maybe not a bad thing  lol
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-16 18:26:50
Hairston:
I would be curious about "the reason for", I must have missed them. It is not added information, it is added MISS-information. This only shows that even the high & mighty Gregory can make misstake & furthermore with good intention. The real shadow emperor is lord  Spoon.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-08-16 19:19:19
Quote
I rip without correcting offset & then check with cuetools because I want a cuetools log.


If you just ripped with the right offset and do a verify, you would be wasting less time.
A verify is much quicker than a verify and offset fix and gives a log too.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-16 20:04:57
Tigerman:
You're right.
My problem with speed is more about drive hanging forever trying to rip a damaged CD than pure CPU speed.

As I use flac -4 (significantly faster then -5) & will soon (can't wait for Q1 2010) have a nehalem clarkdale Core i3 530 (or Pentium G6950 depending on mobo price), CPU speed will not be a problem anymore.

I may switch too flac -1 if this is still not fast enough to my taste (Edit:doubtfull). Accuraterip as affected my flac setting too, I use -4 over -5 for the decoding speed gain. In fact Accuraterip has changed my audio world in many ways.

I agree my method is actually a bit painfull with my athlon/barton 3000+. I am already a step ahead & do as if I already had my clarkdale
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MUSIKMAKER on 2009-08-16 20:07:53
i'm new to the forums i have come across a problem after using the latest version 2.04a. before trying out the latest version i was using 1.03 with no problems at all. i am running the 64 version as i am using vista home premium64.

i started the program and loaded a cue file, verified the music file and noticed the offset was wrong, i decided to encode and veryfy in a default location only to find no matter what lossless audio output and no matter if i am encoding to simgle or tracks only one audio file is created and always with the name '%tracknumber%. %title%'.

i tried firing up cuetools 1.03 which i had been using hours before with no problem and to my suprise that started encoding the files the same as above.

just wondering if anyone knows what has happened due to me using the latest version and how i can solve the problem, until i find a fix it is impossible to encode files propery using any of the previous versions of cuetools.

thank you
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Hairston on 2009-08-16 20:38:33
Hairston:
I would be curious about "the reason for", I must have missed them. It is not added information, it is added MISS-information. This only shows that even the high & mighty Gregory can make misstake & furthermore with good intention. The real shadow emperor is lord  Spoon.

I don't know if I would call it misinformation, it is just "other" information. Showing this info doesn't make your rips any less accurate to someone who knows what it means.

For those people who don't understand the concepts of "pressings" as it relates to the AccurateRip DB should stick to the non-verbose log. I can't speak for the rest of us, but I don't mind seeing it in the logs.

We don't need to debate this any further, I'm just stating my opinion.

Keep up the good work!

I love the new feature of checking a directory of music files against the AR database without having to create a CUE sheet first. What a great idea!

I have a question though, I see in this new version there is no checkbox to turn off automatic offset fixing like in the other version. Or does it only automatically fix offsets when you are doing a batch? I guess my concern is that I really don't want it fixing offsets automatically on my encodes unless I specifically tell it to with a specified offset of my choice (not one automatically selected for me by CUETools).

This is another question that may have already been answered here and I apologize if it has, I am short on time, but is it possible to tell the new version to look in an alternate location to put its option files? As of right now I'd like to still use v1.9.5 for the time being and using v2.0.4a overwrites these files with its own settings and munges up v1.9.5 when I switch back.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MUSIKMAKER on 2009-08-16 20:45:40
found out the solution to my problem...had to delete the settings file...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-08-16 20:46:56
Tigerman:
You're right.
My problem with speed is more about drive hanging forever trying to rip a damaged CD than pure CPU speed.

As I use flac -4 (significantly faster then -5) & will soon (can't wait for Q1 2010) have a nehalem clarkdale Core i3 530 (or Pentium G6950 depending on mobo price), CPU speed will not be a problem anymore.

I may switch too flac -1 if this is still not fast enough to my taste (Edit:doubtfull). Accuraterip as affected my flac setting too, I use -4 over -5 for the decoding speed gain. In fact Accuraterip has changed my audio world in many ways.

I agree my method is actually a bit painfull with my athlon/barton 3000+. I am already a step ahead & do as if I already had my clarkdale


I wasn't talking about the secure vs burst.
I just pointed out that setting the right offset would save tons of time reencoding.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-16 21:04:28
It's true but you cannot be sure your pressing is the most popular in database, so it's random anyway.
But I agree if it happens that my pressing is the most popular in database then you're right, it's faster.
I'll set my offset correctly to save some watts  Fixing offset is a eco-responsible, after all these years I found a use for offsets !!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-08-16 21:13:55
It's true but you cannot be sure your pressing is the most popular in database, so it's random anyway.
But I agree if it happens that my pressing is the most popular in database then you're right, it's faster.
I'll set my offset correctly to save some watts

Are you really trying to tell me that you correct the offset to the most popular one?
That's imho a complete waste of time. You're only moving a few samples.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-16 21:22:33
Yes, but I am tired of explaining all the reasons why I am doing this  lol (It's bedtime here, sorry)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Hairston on 2009-08-17 02:50:27
I have a question though, I see in this new version there is no checkbox to turn off automatic offset fixing like in the other version. Or does it only automatically fix offsets when you are doing a batch? I guess my concern is that I really don't want it fixing offsets automatically on my encodes unless I specifically tell it to with a specified offset of my choice (not one automatically selected for me by CUETools).

This is another question that may have already been answered here and I apologize if it has, I am short on time, but is it possible to tell the new version to look in an alternate location to put its option files? As of right now I'd like to still use v1.9.5 for the time being and using v2.0.4a overwrites these files with its own settings and munges up v1.9.5 when I switch back.

I figured both of these out on my own. It just wasn't obvious at first glance with the new UI.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-17 03:24:40
i think i'll just make some reinforcements to a couple of statements written in this post recently (you guys have been busy.. 20 something new posts since i last checked!) i don't really expect a response to this except for the last one, i'm just throwing some last thoughts out on this, cause i agree the topic is starting to become stale.

1- a real-life example to demonstrate accurate rips showing as wrong offset: i am going through the process of re-ripping my cd collection as single WAV+CUE, as my original rips were done multiple WAV+non-compliant cue. i know i could just rejoin, but this is easier for me, plus i can make these rips with new confidence that i have obtained by reading the board here. so -- after ripping some 40 CD's so far, i have gotten 39 perfect matches (minimum of more than 2 matches). just for extra paranoia i use secure rip + test&copy (overkill, some would say... it's just a matter of time and resources to make this personal opinion). still takes only a few minutes to rip a CD. i have 1 CD that has no matches. actually, two. this is a perfect example of why "no accuraterip matches" does not mean the rip is WRONG. the actual CD was "The Agony Scene - The Agony Scene". it had two matches, but was -17 and -685 offset from my rip. now, after ripping 39 other CD's with perfect results, and i do this rip, which has matching test+copy CRC's, i can say this rip is CORRECT by simple logic. it is just simply a third pressing of this cd that no one has ripped/submitted yet. besides, the other two matches were only 2 each... making for only 4 total matches on this disc, PERIOD. this demonstrates and (mostly) proves that just because your rip has no matches, it doesn't mean you need to correct the offset. as sauvage said, i believe... this would only to give you the "warm and fuzzies" that you're at least matching up with others. (how do you know those other rips were not bad rips to begin with, and yours is actually the correct one? you can't!) with an accuracy of of only 2 and 2 on the other "pressings", you could theoretically have two people that have ripped the same disc twice, wrong.


2- the end-all, be-all i think when talking about 'features' is to make them OPTIONS and not hard features. this could complicate things if you give people too much choice as we mentioned before, but ultimately, it's a way of making both crowds happy... they can enable or disable the feature... hence why a lot of times you see programs call it "PREFERENCES", and giving the end-user the power to choose the way/format/action they prefer. i think this is the answer to feature inclusion rather than arguing for or against.

3- does it really matter if your rip comes back as "no matches" or shows matches with different offsets if you know you ripped yours correctly, with the correct offset, etc... or like in my situation where i have 39 match record so far... i can say quite safely that my settings are configured right. that 1 cd that came back with no matches... the only reason i could should care that it doesn't match to something in the DB is if i were to post to the public, and them deem it as a bad rip! i know i did the rip, i know it's solid... case closed. i don't put it up on torrent or newsgroups or these things like "dirty pirate" lol... (gets me every time! i love the nickname!)

4- i can think of 1 situation where correcting offset *is* a viable and useful thing to do, and this is the case when CD's are ripped with 0 offsets. i know that one time, years back, i had just re-installed my OS and re-setup my EAC. i forgot to put in my cd burner's offset (this was before accuraterip came with EAC)... i ripped the CD with the incorrect offset of 0. i know now that particular drive's offset was +46. now i have the option (if the disc was lost or damaged or i didnt want to re-rip), i could "fix offset" and apply the correct offset to the audio rip (hopefully and probably replacing nothing but original silence/null samples). this is the useful case, when you KNOW the wrong settings were used... most often by you seeing in the log that drive offset is 0. haha as sauvage puts it "dirty pirates" (still makes me laugh every time i see this phrase) may download a rip, see the person who ripped it had no idea or care what accurate ripping was, and ripped it without making any drive offset correction, etc. then you run it through CUETools, or TripleFLAC or what have you... and you see there is only other 1 pressing with say... 57 matches at an offset of +72. "dirty pirate" could correct this by using fix offset +72, and feel better that the rip is now matching the rest.

5- sauvage, how long does it take you to rip a cd in secure mode/compress with -8 in flac/encode in lame --preset -extreme (slow, high quality)? i am just curious as it must be slow enough for you to trade time vs. disc space. just for reference, my rip time for an average CD in secure mode, test&copy is around 10 minutes. to encode that WAV file into FLAC using "-8 -v" took approximately 1 minute, 40 seconds on a 44 minute CD -- and this is with several programs running too. you make me curious as to how long it would take using burst mode in EAC or a lower compression setting in FLAC. and my computer isn't really "great" by standards, it's a Core 2 Duo 2.4ghz. but just *personally* i *prefer* to use highest compression, highest chance of a quality rip.. even if it takes more time. you seem to be the opposite (that is, with compression at least).



makes me wonder if i am wasting time doing this. if i can test and find that i consistently get the same results in burst mode, and find i never get test/copy mismatches... then yes... with presence of cuetools/accuraterip, i can still be confident i did a good rip, regardless of settings used. i may consider this.


one CD i find difficult to rip is TOOL - 10,000 days. there must be some sort of copy protection or something on this cd, as about halfway through the disc, it gets SUPER slow (would take like an hour or more to rip the cd fully), and i get all kinds of sync errors and re-reads over and over. the CD surface is pristine... not a single scratch, fingerprint, NOTHING. has anyone else experienced this with this particular CD if you have ripped it? i wonder if the pressing i got was bad or there is a bad part physically on the CD when created at the factory or what... or is this as said, some copy protection mechanism. i wonder. i will search the forums, see what i find.

[edit]: i did find some posts about it... some concerns mentioning some (or all?) copies were manufactured by SONY BMG MUSIC, which mine is... and that whole rootkit/copy protection fiasco. i think that was around the same time? it is the original CD bought in a retail store in the US. i'll try and find out what's going on and report back.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-17 06:41:04
People are really starting to annoy me with their "correct offset", there is no absolute correct offset. We should use something like "adjust" offset instead of "fix" or "correct" offset. I never said that having a rip with "no match" according to target offset was a mistake, I only said that, to me, it was useless spam that I could remove by "adjusting offset" to the most popular in database because I don't care about burning.
It's either you care about having an absolute exact copy of the CD you ripped in order to re-burn it or you don't care about it & offset is useless for you.

As Spoon said "a match is a match", you don't need match on your own pressing offset to know that your CD is accurate. You need a match on all tracks within the same offset no matter the offset.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-08-17 10:55:41
All this offsets talks is making me paranoid...
Let's say, I know that this disc came from a drive with no offset correction (0): (log shortened, the results for the other tracks are the same)
Code: [Select]
Track    [ CRC    ] Status
24    [3ca99ed1] (00/18) No matches
Offsetted by -658:
24    [d1259d71] (09/18) Accurately ripped as in pressing(s) #1
Offsetted by 6:
24    [f2f1a1f1] (07/18) Accurately ripped as in pressing(s) #2
Offsetted by 2244:
24    [89de2f91] (02/18) Accurately ripped as in pressing(s) #3

Can I say "I have a perfect rip, now I can burn it on a archival DVD so it will last forever"?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-17 12:23:08
buddhabar:
I cannot answer because I don't know what "perfect" means for you: it depends on if you want perfect audio data backup or a perfect CD architecture backup. Offset has nothing to do with audio data quality as long as gaplessness is not broken & samples from beginning & end are not cut off. Then for the same "perfect" audio data there is several "perfect" CD architecture, with only some samples of silence shifting within the margin of the gap lenght in sample.

If it where not silence but real audio data like some people are suggesting then accuraterip couldn't find matching CRC between pressings. This is how I understund Accuraterip, now it seems many people disagree with me but none has provided any real life proof of their claims. I may be wrong afterall, I dunno.

To be short according to me yes your backup is "perfect" no matter if the offset is 0 or adjusted by -658, 6 or 2244.

PS: You cannot judge accuracy of a full CD with a single track, it may sound stupid but I prefer add it...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2009-08-17 14:42:14
@sauvage78

Why don't you start your own thread for this discussion. You are filling up the CUETools thread with ranting that has nothing to do with the functioning of CUETools. The thread is long enough for people to sift through to fine info on CUETools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-17 15:12:32
This is not my discussion, it all started by answering question asked here.

I didn't ask anything to anybody & I don't need anyone to tell me what to do with my music.

I answered the questions to the best of my knowledge, now if people are not pleased by what they hear & want to fake there mind thinking that they have a "perfect rip" because they use a "perfect offset", it's their problem.

Now I have the feeling that I am walking-on-the-head & that the-world-is-reversed with this thread ... because it's people who think that their rips are "perfect" because they use "perfect offset" that are trying to teach me that I am a moron who think that I will make my own rip "better" by adjusting offset to the most popular in database, when the truth is that personnaly I don't give damn about offset while on the contrary they care a lot about their "perfect offset".

You think adjusting offset can break gaplessness, OK, prove it. Personnaly I tryed & I couldn't prove it.
Indeed adjusting offset randomly can break gaplessness but not between two matching accuraterip because you stay within the boundary of gaps (silence samples between song). If I am wrong, then teach me.

Edit: It seems people are misslead because CRC with different offset/pressing are different in the logs, as far as I understund they are different because they include silent sample at different place, but the CRC without silence is the same (but not displayed because it's useless spam) which mean the data is the same no matter how you fix offset.

I already asked about a separate threads, one for cuetools bugs & one for accuraterip & logs, I wasn't heard.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-08-17 18:04:37
I recall I made my own test about gaplessness with an Alice in Chains CD & I didn't damage my gaplessness, the CRC of splitted songs with & without correcting offset was the same. I double checked the split stop/start point in audacity. Sorry I didn't post my result at time. I may be wrong & maybe my test was not enough & I ended with a special case. I don't know.

Shame, it would've been nice to read that.

The discussion about this setting is interesting when it deals about if it can or not damage gaplessness

I think this is one other thing which made us misunderstand each others. I've not commented on this at all.. and what I understand, nor have Gregory and Greynol. The harmfulness I wrote was the start or ending cuts of samples of an album, not track. Maybe this technical talk is like a Boeing 747 to me, goes waaayy over my head.

I don't intend to burn my rip, maybe you intend to burn yours, that's maybe why we have a different point of view.

Spot on! I didn't know that you don't care about the "identical" backup copy of your albums. I'm not burning my rips.. yet.. hopefully never have to resort to that.. but it's good to have an identical copy backed up.

I rip without correcting offset & then check with cuetools because I want a cuetools log.

This also explains better what you're doing. You don't want EAC log at all. I think I do now understand what you're doing.

It will only lead me to shut my mouth ... which is maybe not a bad thing  lol

No no. Don't say that. I'm sorry to see that you got so much pressure these past days. Hopefully you'll stay with us.

P.S. I never intended to insinuate that you're a pirate.. if that's what you thought. I merely, out loud generally, wondered what uses I can think of with that feature.. and only one "proper" came to my mind, and one not so "proper".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2009-08-17 18:40:02
it had two matches, but was -17 and -685 offset from my rip. now, after ripping 39 other CD's with perfect results, and i do this rip, which has matching test+copy CRC's, i can say this rip is CORRECT by simple logic.

I'm not quite sure what you were trying to say but in any case, you do know that matching T&C CRC's is not a proof of accurate rip? It doesn't matter how many (or few) CD's you've ripped ok before that. All that the matching CRC's do tell you is that the track data was read exactly the same in both test and in copy. Correct data or corrupted data.

does it really matter if your rip comes back as "no matches" or shows matches with different offsets if you know you ripped yours correctly, with the correct offset, etc... or like in my situation where i have 39 match record so far... i can say quite safely that my settings are configured right. that 1 cd that came back with no matches...

But you can't tell that the CD was accurately ripped without AR. So no matches makes you fall back to the CRC's which doesn't guarantee accuracy (+ to track quality %'s). Different offset matches (all tracks within at least one offset.. and with 1 matches if it's not your own submission) are ok. The "fact" that your settings are correctly configured doesn't guarantee you accurate rips.

one CD i find difficult to rip ... about halfway through the disc, it gets SUPER slow (would take like an hour or more to rip the cd fully), and i get all kinds of sync errors and re-reads over and over. the CD surface is pristine... not a single scratch, fingerprint, NOTHING. has anyone else experienced this with this particular CD if you have ripped it?

Yes I've, not with that CD but another. Bogged my mind. No visible marks, nothing. And no protections. Still had lots of problems reading it. Usually the "good" protections kick in with every track and makes EAC re-read like mad in many places within one track.. so it should not be protection with your CD. If you browse to the CD drive in Win and it has only .cda ending files, the CD doesn't have any protections.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: stiky on 2009-08-19 22:35:54
i get the error: "Synchronization Lost" on all builds

How do i fix this? i got .NET & C++ installed....
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: GHammer on 2009-08-20 02:52:12
What does all the offset items have to do with the app the thread is for?

Take this to a seperate thread please.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rpp3po on 2009-08-20 17:00:39
Would it be possible to implement a "Use gaps appended + HTOA (only when HTOA isn't empty)" switch?

Most of the time a simple PREGAP is sufficient.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fuki on 2009-08-22 18:40:03
Can somebody please explain to me what happened to the other 106 matches?

Code: [Select]
D:\Music\FLAC\Albums\The White Stripes\2 De Stijl\2 De Stijl.cue: rip accurate (17/123).
[Verification date: 22.8.2009 19:37:06]
[Disc ID: 0011dcf6-00b57a59-b008d20d]
Offset applied: 667
Track [ CRC    ] Status
 01 [6c8cd435] (18/124) Accurately ripped
 02 [35460eef] (18/126) Accurately ripped
 03 [c2da991b] (18/125) Accurately ripped
 04 [c37d7193] (18/124) Accurately ripped
 05 [654e275a] (18/125) Accurately ripped
 06 [6a655caa] (17/123) Accurately ripped
 07 [60b24313] (17/124) Accurately ripped
 08 [b79ef599] (17/123) Accurately ripped
 09 [263edf3a] (17/124) Accurately ripped
 10 [caa96eb7] (17/124) Accurately ripped
 11 [23bc4f57] (17/124) Accurately ripped
 12 [df2e22f8] (17/124) Accurately ripped
 13 [c0aaf0a9] (17/123) Accurately ripped

Track [ CRC32  ] [W/O NULL] [  LOG  ]
 -- [310B18D0] [9D75D106]
 01 [408CDD38] [0ACC2641] W/O NULL
 02 [D763687A] [94AE1449] [C13C4398]
 03 [227045C4] [9B721BB3] [72B66554]
 04 [886A95E8] [AC4B1540] W/O NULL
 05 [9D50A2B0] [1DA3CED4] W/O NULL
 06 [80BA0F68] [F8794B93] W/O NULL
 07 [A4EC5F1B] [210CF406] W/O NULL
 08 [09063A6D] [875F5C71] W/O NULL
 09 [2D62BD5C] [D03045F8] W/O NULL
 10 [D2B51174] [C872FF19] [15678878]
 11 [CD0B1B5D] [7EE51525] [56E565D2]
 12 [21D79E04] [A02872C6] W/O NULL
 13 [90575028] [735F8920] W/O NULL
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-22 21:48:44
As far as I understood, the disk ID is the same but the data is entirely different, it can be a kind of remaster (or just a reissue with some kind of audio effect, supposed to increase quality, applied) or made from another master without any bonus track, any bonus Data track or any pregap difference which would affect the disk ID. (nor any song lenght difference & so on ...) It could also be that one of the two pressings is only a reissue burned with a crap software that altered the data in some way (either corruption or weird stuff like audio watermark), I dunno, there seems to be plenty of possibilities. As the other pressings are not listed this is not just an offset issue. It seems that there is truly several pressings for this CD. I may be wrong but that's how I understand it.

Anyway your CD is accurate.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pico1965 on 2009-08-23 10:57:11
Hii at all.

The version 2.0.4.a of the program allways working well for me.

Today after the XPSP3 live update the program now return this error and return in the initial state (waiting for press the go button):
(http://img34.imageshack.us/img34/1976/immagineniv.jpg)

What's append?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-08-23 16:22:02
What does this mean?
Quote
Padded some input files to a frame boundary

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-23 16:28:19
As far as I understund, it means the cut point didn't fall on a full frame so cuetools added samples of silence to make it fall on a full frame. It's something like that. I already encountered this when I tried to made a CDImage+cue of NIN free OEF releases which were released as online separate tracks & weren't compliant to CD. It shouldn't matter if it matches, I think. You can encounter the opposite "Truncated xxx extra samples in some input files".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-23 16:48:12
What is the difference between "Playstation type data track" & "CD-Extra data track" other than the fact that cuetools cannot guess the lenght of missing playstation data ? Will the Disk ID be recognized if I simply delete the playstation data track in cue ? (Don't seems to work) Is the rip unusable with cuetools if I don't have the playstation data length at all ? The cue is weird, Track 1 is data, F2K will not even load it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-23 17:03:58
What is the difference between "Playstation type data track" & "CD-Extra data track" other than the fact that cuetools cannot guess the lenght of missing playstation data ? Will the Disk ID be recognized if I simply delete the playstation data track in cue ? (Don't seems to work) Is the rip unusable with cuetools if I don't have the playstation data length at all ? The cue is weird, Track 1 is data, F2K will not even load it.

CD-Extra is an audio disc format with data track after the audio.
Playstation type has data track before the audio.
CUE sheets look a bit differently, but in both cases you have to know data track length to be able to use AccurateRip.
With playstation type there's no easy way to guess it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-23 17:06:10
What does this mean?
Quote
Padded some input files to a frame boundary

Thanks

Usually that means that source files are not a valid CD rip. This usually happens if the audio files were edited, or the album is a web release by the artist, which was never meant for CD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-23 17:09:03
Today after the XPSP3 live update the program now return this error and return in the initial state (waiting for press the go button):

No idea yet. We'll see if someone else has the same problem.
What was in that update? There's usually a link to a knowledge base article on the microsoft website in update log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-23 17:10:01
Ok thks
I think I will just delete the data track in this cue as the fact that F2K will not load it is very unpractical anyway.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pico1965 on 2009-08-23 17:25:58
Today after the XPSP3 live update the program now return this error and return in the initial state (waiting for press the go button):

No idea yet. We'll see if someone else has the same problem.
What was in that update? There's usually a link to a knowledge base article on the microsoft website in update log.



Windows XP Aggiornamento per Windows XP (KB961118)

Microsoft .NET Framework 3.5 Service Pack 1 e .NET Framework 3.5 Family Update per .NET, dalla versione 2.0 alla 3.5 (KB951847) x86

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-23 18:48:44
This is an old update. It should have come more than half a year ago.
Maybe you should try reinstalling http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f&displaylang=en)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-23 21:25:39
This is an old update. It should have come more than half a year ago.
Maybe you should try reinstalling http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f&displaylang=en)


i agree.. and maybe if that fails, the vc++ redistro, that fixed mine (i didn't look at the actual update KB to see what it updated, sorry).

as always, i recommend this tool to at least verify that you have no problems with your .NET installs. See a description, screenshot and links:

Quote
This .NET Framework setup verification tool is designed to  automatically perform a set of steps to verify the installation state  of one or more versions of the .NET Framework on a computer.  It will  verify the presence of files, directories, registry keys and values for  the .NET Framework.  It will also verify that simple applications that  use the .NET Framework can be run correctly.


Here is a link to the website for the product (http://blogs.msdn.com/astebner/pages/8999004.aspx)
Here is the direct download link (http://blogs.msdn.com/astebner/attachment/8999004.ashx)

(http://i46.photobucket.com/albums/f132/poisonfortheweak/netverifier.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-24 01:04:20
As I am thinking about it, one small change that I would like to see in the future is empty silence tracks reported as accurate. I have several of those:

Danzig - 1993 - Thrall-Demonsweatlive (EP)
Danzig - 1994 - Danzig 4 (Digipack)
Korn - 1998 - Follow The Leader
Nine Inch Nails - 1992 - Broken (EP) (Digipack)

Cuetools reports them as not accurate due to [00000000] (00/00) No matches.
There should be an exception for empty tracks as this is a special case.
An empty track doesn't need a match to be accurate

[00000000] (00/00) Empty track. + "Accurately ripped" in batch log would be more usefull, IMHO.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2009-08-24 10:34:21
Gregory, just to let you know: both links in the About... box don't work :-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pico1965 on 2009-08-24 18:23:09
Thank you for your interest in my problem.

as always, i recommend this tool to at least verify that you have no problems with your .NET installs. See a description, screenshot and links:


.NET Framework 2.0 SP2
Product verification succeded!
.NET Framework 3.0 SP2
Product verification succeded!
.NET Framework 3.5 SP1
Product verification succeded!


This is an old update. It should have come more than half a year ago.
Maybe you should try reinstalling http://www.microsoft.com/downloads/details...;displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f&displaylang=en)


Do it.
Nothing new.

I repeat

as always, i recommend this tool to at least verify that you have no problems with your .NET installs. See a description, screenshot and links:


.NET Framework 2.0 SP2
Product verification succeded!
.NET Framework 3.0 SP2
Product verification succeded!
.NET Framework 3.5 SP1
Product verification succeded!


What I can do for reuse the program?

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-25 06:36:21
I'm not sure if this validation tool verifies configuration files.

Check your machine.config (Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config or something like this).
Try adding something like this to the configSections section.
Code: [Select]
    <sectionGroup name="system.serviceModel" type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="behaviors" type="System.ServiceModel.Configuration.BehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
      <section name="bindings" type="System.ServiceModel.Configuration.BindingsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
      <section name="client" type="System.ServiceModel.Configuration.ClientSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
      <section name="comContracts" type="System.ServiceModel.Configuration.ComContractsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
      <section name="commonBehaviors" type="System.ServiceModel.Configuration.CommonBehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly"/>
      <section name="diagnostics" type="System.ServiceModel.Configuration.DiagnosticSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
      <section name="extensions" type="System.ServiceModel.Configuration.ExtensionsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
      <section name="machineSettings" type="System.ServiceModel.Configuration.MachineSettingsSection, SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly"/>
      <section name="serviceHostingEnvironment" type="System.ServiceModel.Configuration.ServiceHostingEnvironmentSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
      <section name="services" type="System.ServiceModel.Configuration.ServicesSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </sectionGroup>

Or this: http://www.dotnettech.net/BCL/Article.aspx...0%2f430270.aspx (http://www.dotnettech.net/BCL/Article.aspx?ArticleID=26318&Url=http:/%2fweblogs.asp.net%2fbhouse%2farchive%2f2005%2f11%2f10%2f430270.aspx)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-08-25 17:31:44
Must say, I like this program more and more. I don't think I use the full potential of the program yet, but I'm trying.

I also have 2 requests.
At the bottom of the log there are 2 or 3 rows of checksums (CRC, without null, (if exists) log).
It would be nice if you could add a fourth: AR crc.
I have to use tripleflac now and again to compare two rips who aren't in the AR database yet.
It would be nice if Cuetools could give me the AR checksums.

After updating to 2.0.4a the program asks if it's all right to overwrite a previous log.
Very annoying if you want to batch check a batch which wasn't in the database last time and you want to do a recheck.
Also very annoying when trying out different pregaps.
Couldn't find a setting to disable this message. My second request: I would appreciate if you added such a setting.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radivx on 2009-08-26 22:08:07
Hi,
Thnx for a the 2.0.4a version. The apps works and looks very good now.

I'm still looking for the option to output filenames in lowercase.
Integrating the feature into CueTools will save us lowercase guys for a massive
amout of work when it comes to editing the cue sheet and m3u files.

Also, for some reason the "Force ANSI filenames" changes invalid characters to underscores (or perhaps spaces?). There should either be possible to define a ruleset (ie. define that for example & is changed to and, : is changed to _-_) or just delete the character. Personally I think the extra underscores is a bit annoying.

  TRACK 04 AUDIO
    TITLE "We Share Our Mothers' Health"
    PERFORMER "The Knife"
    INDEX 00 06:08:64
FILE "04-The_Knife-We_Share_Our_Mothers__Health.flac" WAVE

I hope that you will consider my suggestions for 2.0.5.

Would also love replay-gain support for multiple FLAC files (not necessarily inside the cue file).
Have you also considered compiling Linux compatible binaries using Mono? Probably some extra work, but I promise I'll use it =)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-27 01:26:09
Hi,
Thnx for a the 2.0.4a version. The apps works and looks very good now.

I'm still looking for the option to output filenames in lowercase.
Integrating the feature into CueTools will save us lowercase guys for a massive
amout of work when it comes to editing the cue sheet and m3u files.

Also, for some reason the "Force ANSI filenames" changes invalid characters to underscores (or perhaps spaces?). There should either be possible to define a ruleset (ie. define that for example & is changed to and, : is changed to _-_) or just delete the character. Personally I think the extra underscores is a bit annoying.

  TRACK 04 AUDIO
    TITLE "We Share Our Mothers' Health"
    PERFORMER "The Knife"
    INDEX 00 06:08:64
FILE "04-The_Knife-We_Share_Our_Mothers__Health.flac" WAVE

I hope that you will consider my suggestions for 2.0.5.

Would also love replay-gain support for multiple FLAC files (not necessarily inside the cue file).
Have you also considered compiling Linux compatible binaries using Mono? Probably some extra work, but I promise I'll use it =)


doesn't the program support foobar variables/functions? i thought i read that... i could be completely wrong though.. but if it does, you could try and use the function $lower(%artist%-%title%) or whatever you want.

I didn't even notice the "a" version was out until yesterday... what is changed? i notice it will ask to overwrite accuraterip log if it exists. seems there may be more default profiles? i also just noticed there is a 64 bit version too... maybe i overlooked this, but it's nice since i'm running 64-bit OS.

yeah, btw, i'm pretty sure it supports foobar naming schema, cause i'm looking in the options and i see it is using some variables. check out this wiki for all of the modifiers (not sure how many or again, if they are even supported, but it's worth a shot): Foobar Title Formatting Reference (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Reference)  [edit: actually i found the exact info on the CUETools homepage... here is the link to it (http://www.cuetools.net/doku.php/cuetools:template).

so anyone know what else is changed or is there a changelog?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-27 07:13:24
2.0.4a is mostly minor interface fixes, nothing important.

No special binaries required for Linux, x86 ones should work, but... The problem is it only supports wav files when run on linux. This will hopefully change in the next version, when a pure managed FLAC encoder/decoder (http://www.hydrogenaudio.org/forums/index.php?showtopic=74242) will be added.

I will add lowercase option, but more complicated things (like the rulesets) will probably have to be done using foobar-style functions, i will add more of them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: patmcg on 2009-08-27 08:49:41
Hi,

I'm trying to use the "Verify" option on a FLAC encoded album. The program fails with the following error:

Quote
Exception: Could not load file or assembly 'CUETools.Codecs.TTA, Version=1.0.3507.34128, Culture=neutral,
PulicKeyToken=null' or one of its dependencies. This application has failed to start because the application
configuration is incorrect. Reinstallign the application may fix this problem. (Exception from HRESULT: 0x80073681):
This application has failed to start because the application configuration is incorrect. Reinstalling the application may
fix this problem. (Exception from HRESULT: 0x800736B1)


Any idea what the problem is?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-27 09:07:01
If you are getting an error loading CUETools.Codecs.TTA, you need to install this update (http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: patmcg on 2009-08-27 12:00:27
If you are getting an error loading CUETools.Codecs.TTA, you need to install this update (http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en)



Thanks I found it. I'm not complaining, but I would suggest you detect that issue in the program and point the user to the required update, instead of the funky error message.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: chrismrx on 2009-08-27 23:46:18
Great configuration, many thanks Gregory !

In 2.0.4a version when I encode album with various artists in embedded flac, the artists name is not written in line "PERFORMER". It's only write : "various".

Original Cue sheet :

Code: [Select]
REM GENRE Soundtrack
REM DATE 1980
REM DISCID 90099B0B
REM COMMENT ExactAudioCopy v0.99pb4
PERFORMER "Various"
TITLE "The Blues Brothers"
REM REPLAYGAIN_ALBUM_GAIN +0.25 dB
REM REPLAYGAIN_ALBUM_PEAK 0.710358
FILE "Various - The Blues Brothers.wav" WAVE
  TRACK 01 AUDIO
    TITLE "She Caught The Katy"
    PERFORMER "The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN +0.38 dB
    REM REPLAYGAIN_TRACK_PEAK 0.529999
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Peter Gunn Theme"
    PERFORMER "The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN +1.53 dB
    REM REPLAYGAIN_TRACK_PEAK 0.575104
    INDEX 00 04:09:27
    INDEX 01 04:12:40
  TRACK 03 AUDIO
    TITLE "Gimme Some Lovin'"
    PERFORMER "The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN -0.28 dB
    REM REPLAYGAIN_TRACK_PEAK 0.587189
    INDEX 00 07:58:48
    INDEX 01 08:02:05
  TRACK 04 AUDIO
    TITLE "Shake Your Tailfeather"
    PERFORMER "Ray Charles & The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN -0.14 dB
    REM REPLAYGAIN_TRACK_PEAK 0.582825
    INDEX 00 11:07:16
    INDEX 01 11:11:58
  TRACK 05 AUDIO
    TITLE "Everybody Needs Somebody To Love"
    PERFORMER "The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN -0.27 dB
    REM REPLAYGAIN_TRACK_PEAK 0.598083
    INDEX 00 13:59:64
    INDEX 01 14:03:18
  TRACK 06 AUDIO
    TITLE "The Old Landmark"
    PERFORMER "James Brown"
    REM REPLAYGAIN_TRACK_GAIN +1.68 dB
    REM REPLAYGAIN_TRACK_PEAK 0.455566
    INDEX 00 17:25:69
    INDEX 01 17:28:45
  TRACK 07 AUDIO
    TITLE "Think"
    PERFORMER "Aretha Franklin"
    REM REPLAYGAIN_TRACK_GAIN +0.69 dB
    REM REPLAYGAIN_TRACK_PEAK 0.584290
    INDEX 00 20:25:37
    INDEX 01 20:27:18
  TRACK 08 AUDIO
    TITLE "Theme From Rawhide"
    PERFORMER "The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN +1.66 dB
    REM REPLAYGAIN_TRACK_PEAK 0.529633
    INDEX 00 23:40:51
    INDEX 01 23:43:73
  TRACK 09 AUDIO
    TITLE "Minnie The Moocher"
    PERFORMER "Cab Calloway"
    REM REPLAYGAIN_TRACK_GAIN +2.12 dB
    REM REPLAYGAIN_TRACK_PEAK 0.554657
    INDEX 00 26:20:56
    INDEX 01 26:23:00
  TRACK 10 AUDIO
    TITLE "Sweet Home Chicago"
    PERFORMER "The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN -0.28 dB
    REM REPLAYGAIN_TRACK_PEAK 0.710358
    INDEX 00 29:45:71
    INDEX 01 29:49:63
  TRACK 11 AUDIO
    TITLE "Jailhouse Rock"
    PERFORMER "The Blues Brothers"
    REM REPLAYGAIN_TRACK_GAIN +0.23 dB
    REM REPLAYGAIN_TRACK_PEAK 0.546844
    INDEX 00 37:39:74
    INDEX 01 37:41:18

Embedded Cue sheet :

Code: [Select]
REM GENRE Soundtrack
REM DATE 1980
REM DISCID 90099B0B
REM COMMENT ExactAudioCopy v0.99pb4
PERFORMER "Various"
TITLE "The Blues Brothers"
REM REPLAYGAIN_ALBUM_GAIN +0.25 dB
REM REPLAYGAIN_ALBUM_PEAK 0.710358
FILE "Various - The Blues Brothers.flac" WAVE
  TRACK 01 AUDIO
    TITLE "She Caught The Katy"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN +0.38 dB
    REM REPLAYGAIN_TRACK_PEAK 0.529999
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Peter Gunn Theme"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN +1.53 dB
    REM REPLAYGAIN_TRACK_PEAK 0.575104
    INDEX 00 04:09:27
    INDEX 01 04:12:40
  TRACK 03 AUDIO
    TITLE "Gimme Some Lovin'"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN -0.28 dB
    REM REPLAYGAIN_TRACK_PEAK 0.587189
    INDEX 00 07:58:48
    INDEX 01 08:02:05
  TRACK 04 AUDIO
    TITLE "Shake Your Tailfeather"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN -0.14 dB
    REM REPLAYGAIN_TRACK_PEAK 0.582825
    INDEX 00 11:07:16
    INDEX 01 11:11:58
  TRACK 05 AUDIO
    TITLE "Everybody Needs Somebody To Love"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN -0.27 dB
    REM REPLAYGAIN_TRACK_PEAK 0.598083
    INDEX 00 13:59:64
    INDEX 01 14:03:18
  TRACK 06 AUDIO
    TITLE "The Old Landmark"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN +1.68 dB
    REM REPLAYGAIN_TRACK_PEAK 0.455566
    INDEX 00 17:25:69
    INDEX 01 17:28:45
  TRACK 07 AUDIO
    TITLE "Think"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN +0.69 dB
    REM REPLAYGAIN_TRACK_PEAK 0.584290
    INDEX 00 20:25:37
    INDEX 01 20:27:18
  TRACK 08 AUDIO
    TITLE "Theme From Rawhide"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN +1.66 dB
    REM REPLAYGAIN_TRACK_PEAK 0.529633
    INDEX 00 23:40:51
    INDEX 01 23:43:73
  TRACK 09 AUDIO
    TITLE "Minnie The Moocher"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN +2.12 dB
    REM REPLAYGAIN_TRACK_PEAK 0.554657
    INDEX 00 26:20:56
    INDEX 01 26:23:00
  TRACK 10 AUDIO
    TITLE "Sweet Home Chicago"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN -0.28 dB
    REM REPLAYGAIN_TRACK_PEAK 0.710358
    INDEX 00 29:45:71
    INDEX 01 29:49:63
  TRACK 11 AUDIO
    TITLE "Jailhouse Rock"
    PERFORMER "Various"
    REM REPLAYGAIN_TRACK_GAIN +0.23 dB
    REM REPLAYGAIN_TRACK_PEAK 0.546844
    INDEX 00 37:39:74
    INDEX 01 37:41:18

In 1.9.5a version it works !

Can you fix this ?

Sorry for my bad english.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-08-28 08:07:20
anything i should do for 'winetricks' if i were to try to run this via wine?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannymichel on 2009-08-28 08:16:05
i tried running it via wine and got this
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-28 18:32:15
Why wine? Mono (http://www.mono-project.com/Main_Page) is supposed to be used for .NET applications. There are no tricks, but FLAC will only work with next version. Of course you can try to set up an external flac encoder/decoder, i haven't tried it. You go to the setting page, decoders tab, select one of the decoders and press 'insert'. Then select flac extension, path to flac and parameters like "-d %I -o -"; Than at extensions tab select flac and set the default decoder to whatever you named it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-28 18:37:34
Can you fix this ?

I hope  Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-28 22:54:08
Can somebody explain to me what "CDDBId mismatch" means exactly plz? When I first started using cuetools I thought that it was due to missing data track, but I don't think so anymore as missing data track is reported separatly. So far I didn't worry much about "CDDBId mismatch" as it seems it is a rare case.
I think I understand that this is a clash between the calculated CDDBId from my files & the database, but I happen to fall on cases where there is a "CDDBId mismatch" & "Disk not present in database" at the same time, so I don't understand anymore. An ID missmatch could be due to missing HTOA, but then how could cuetools detect this & even sometimes reports valid CRC despite CDDBId mismatch?

In the end, I don't understand what "CDDBId mismatch" means & I slowly start to worry because I already have 4 disks like this on my collection & I only passed half of it through cuetools.

Any help is welcomed
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-08-29 02:32:04
Can somebody explain to me what "CDDBId mismatch" means exactly plz? When I first started using cuetools I thought that it was due to missing data track, but I don't think so anymore as missing data track is reported separatly. So far I didn't worry much about "CDDBId mismatch" as it seems it is a rare case.
I think I understand that this is a clash between the calculated CDDBId from my files & the database, but I happen to fall on cases where there is a "CDDBId mismatch" & "Disk not present in database" at the same time, so I don't understand anymore. An ID missmatch could be due to missing HTOA, but then how could cuetools detect this & even sometimes reports valid CRC despite CDDBId mismatch?

In the end, I don't understand what "CDDBId mismatch" means & I slowly start to worry because I already have 4 disks like this on my collection & I only passed half of it through cuetools.

Any help is welcomed


well.. i think this is the cause, sauvage.... CDDBId is what freedb.org etc, uses to look up artist/tracknames, etc from... they use their own "identifier" to lookup discs.... most likely, i think CDDBid mismatch means that your CUE file says something like REM DISCID or uses the DISCID tag of the file to lookup that on CDDB. in certain cases, you can have two (or more) discs from different artists  with that same ID. that is, it's not unique. there are several of these "disc id" calculations... freedb, Gracenote, musicbrainz, accuraterip; they're all checksums tied to ID numbers which identify a certain disc.

in any case, what your CUE or embedded tag says the discid is, apparently CUETools deems it to be wrong. I could see this happening two ways. 1) it was one of these cases where it happened to be a totally different artist... or possibly the rip was identified as wrong because it was a later or different pressing.

in the case of the double entry wrong/missing.... i could imagine this situation --- your DISCID says this disk is  band X - CD1. CUETools calculates its AR checksum (different than DISCID), and does not find a match in the database.

i could easily reproduce this by picking a rare cd that is not in the database, then add a random DISCID number to my cue/tag... it'll obviously be a mismatch on the disc id.. and will also not be found in AR database.

so main point is DISCID != AR checksum, they're two totally different things. if it says mismatch, AAAAAA is really BBBBBB... then CueTools has obviously found the correct matching disc in CDDB database, and let you know that. that doesn't necessarily mean that your pressing of that CD is the same as the one submitted...

after thinking about it for a sec, just think of it this way --- this is the most simple way i can put it --- you can have the SAME ALBUM but DIFFERENT PRESSINGS. you know this... CDDB does not. DISCID is not unique to pressings/different offsets (or even the same artist/album!). it ignores offsets, etc.. where is AR does not. AR is more accurate in identifying a disc than CDDB. accuraterip never pops up and asks you "is this disk Tool - Undertow or The Beatles - Yellow Submarine?"

Quote
wikipedia: CDDB was designed around the task of identifying entire CDs, not merely single tracks. The identification process involves creating a "discid", a sort of "fingerprint" of a CD created by performing calculations (http://en.wikipedia.org/wiki/Hash_table) on the track duration information stored in the table-of-contents of the CD  ....  Since identification of CDs is based on the length and order of the tracks, CDDB cannot identify playlists in which the order of tracks has been changed, or compilations of tracks from different CDs. CDDB also cannot distinguish between different CDs that have the same number of tracks and the same track lengths.


so CDDB simple takes into account the CD's TOC basically. as said above, it doesn't care what the data is, as long as the number of tracks and their lengths.

these are my thoughts and may be incomplete or incorrect. i do not know all the technical differences -- BUT i will let the master, Mr. Chudov explain it to us, so we know for sure!

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-08-29 04:53:04
Chinch:
Thks for the hint about the REM DISCID in cue sheet, I completely forgot about it.

I had a closer look a my 4 rips with CDDBId mismatch, it seems that you're pointing me to the right direction: the last part of the AR ID that cuetools calculate is always different than the DISCID in the cue sheet.
For example cuetools calculates [Disc ID: 00149761-00c5921c-b00ba00c]
& in same time the EAC cue sheet indicates REM DISCID C40E1F0E
So the clash is between these two numbers in the cuetools log:
CDDBId mismatch: C40E1F0E vs B00BA00C

So now the question is why does these two ID clash ? The answer that comes to my mind is missing HTOA, the HTOA was maybe used in the EAC cue sheet calculation but disapeared as it was not ripped & now cuetools is missing it ? Am I right ? I think I recall old EAC versions didn't rip HTOA in CDImage, CDDBId mismatch could be an hint of this.

This answer leaves me unsatisfied as I have a rip that have a CDDBId mismatch, but still gives me an accurate result, is it possible ? I thought CRC were tied to an ID ... (my other 3 rips with mismatch are not in database) What does it means ? That there is two commercial version of it one with HTOA & one without ? So despite having destroyed my HTOA I still match on the one without ? It's a bit weird as a rationnal explanation.

Is my self-made explanation correct ? Is there other possible cause of CDDBId mismatch ? Does missing data track have anything to do with CDDBId mismatch ? (I don't think so as IMHO cuetools should report both missing data & CDDBId mismatch at the same time if it was the case, but in the beginning I mixed the two in my mind, so I'd better ask to remove the doubt)

Thks Gregory, if you could clear this
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-08-29 10:44:21
CDDBId mismatch: C40E1F0E vs B00BA00C

Yes, this is a mismatch between CDDBid calculated by EAC and stored in CUE sheet, and the one calculated by CUETools.
Remember, that the last digit of CDDBId is number of tracks - that's how i usually detect the presense of data track.
In your case the difference is somehow not one, but two tracks. EAC saw 14 tracks, CUETools sees 12.
I have no idea what that means, to be honest. Maybe some wierdness like two data tracks...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-09-04 19:42:06
Thnx for the answers on CDDBId Mismatch Gregory,
today I found something new that I don't understand, I'd like to have your opinion on it ... it's a CD with an hidden track at the end (track 99) (Marilyn Manson - Antichrist Superstar) & 4 sec silence tracks from track  17 to 98, track 17 being a special case it's silence but not empty CRC (there is some data).

Anyway the thing I don't understand are tracks 20 & 36, these two tracks are empty (CRC [00000000]) but result as Partial match ??? how can this happen ??? I don't understand ... it sounds impossible for me, I don't get it.

Here is the (very looong) log:

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: That's what codebox is for![/size][/b]

Code: [Select]
[Verification date: 04/09/2009 20:07:24]
[Disc ID: 01c6a4f5-62ab4f93-2c122463]
Track [ CRC ] Status
 01 [4b23ce19] (50/233) Accurately ripped
 02 [fa92fa55] (49/236) Accurately ripped
 03 [bc5d380d] (49/236) Accurately ripped
 04 [f9998e90] (49/236) Accurately ripped
 05 [3374440d] (49/236) Accurately ripped
 06 [3d968825] (48/232) Accurately ripped
 07 [9ef2184d] (48/232) Accurately ripped
 08 [0da904b2] (48/230) Accurately ripped
 09 [4c72ce63] (46/230) Accurately ripped
 10 [31355e3d] (46/226) Accurately ripped
 11 [affd1d20] (48/228) Accurately ripped
 12 [8b14ba33] (48/230) Accurately ripped
 13 [5a296fb3] (46/225) Accurately ripped
 14 [94e8fc9e] (47/229) Accurately ripped
 15 [037d4910] (47/224) Accurately ripped
 16 [b00f0484] (47/219) Accurately ripped
 17 [409e21ca] (04/17) Accurately ripped
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [39bceae7] (45/199) Accurately ripped
Offsetted by -1992:
 01 [93bee790] (05/233) Accurately ripped
 02 [382a6ade] (05/236) Accurately ripped
 03 [db79d6cf] (05/236) Accurately ripped
 04 [fba7b773] (05/236) Accurately ripped
 05 [8764309a] (05/236) Accurately ripped
 06 [21f865f6] (05/232) Accurately ripped
 07 [ded2e896] (05/232) Accurately ripped
 08 [3e9837fa] (05/230) Accurately ripped
 09 [8c226b77] (05/230) Accurately ripped
 10 [c0e75c5a] (05/226) Accurately ripped
 11 [180c855b] (05/228) Accurately ripped
 12 [5eb53dab] (05/230) Accurately ripped
 13 [5a51ab4c] (05/225) Accurately ripped
 14 [22707ff5] (05/229) Accurately ripped
 15 [730531e6] (05/224) Accurately ripped
 16 [d6b61fad] (05/219) Accurately ripped
 17 [06583633] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [775ef473] (04/199) Accurately ripped
Offsetted by -1345:
 01 [32c0890a] (05/233) Accurately ripped
 02 [255c6072] (05/236) Accurately ripped
 03 [765b3aa2] (05/236) Accurately ripped
 04 [d8e622f2] (05/236) Accurately ripped
 05 [96f1a995] (05/236) Accurately ripped
 06 [f43a2bcf] (05/232) Accurately ripped
 07 [58ba3a5a] (05/232) Accurately ripped
 08 [a530d2e3] (05/230) Accurately ripped
 09 [f4d4c81b] (05/230) Accurately ripped
 10 [04cae13e] (05/226) Accurately ripped
 11 [b92d4c37] (05/228) Accurately ripped
 12 [ad1b2e23] (05/230) Accurately ripped
 13 [c8a4ab62] (05/225) Accurately ripped
 14 [f5e4633b] (05/229) Accurately ripped
 15 [4fc7c95b] (05/224) Accurately ripped
 16 [6885b061] (05/219) Accurately ripped
 17 [2186eff8] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [208c3fe9] (05/199) Accurately ripped
Offsetted by -1328:
 01 [f55ee0a9] (17/233) Accurately ripped
 02 [822374e5] (17/236) Accurately ripped
 03 [7eb5536f] (17/236) Accurately ripped
 04 [b0aff29f] (17/236) Accurately ripped
 05 [c391e6f8] (18/236) Accurately ripped
 06 [48162003] (17/232) Accurately ripped
 07 [940f5e9f] (17/232) Accurately ripped
 08 [d8f326e2] (17/230) Accurately ripped
 09 [27284532] (17/230) Accurately ripped
 10 [1e059214] (17/226) Accurately ripped
 11 [2ab9565f] (17/228) Accurately ripped
 12 [dea566c2] (17/230) Accurately ripped
 13 [19f804af] (17/225) Accurately ripped
 14 [bd9364c2] (17/229) Accurately ripped
 15 [fd699f25] (17/224) Accurately ripped
 16 [cdab79bf] (17/219) Accurately ripped
 17 [9adb8056] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [2327326f] (15/199) Accurately ripped
Offsetted by -747:
 01 [692f161f] (02/233) Accurately ripped
 02 [4218ab29] (00/236) No matches
 03 [c0035400] (00/236) No matches
 04 [747baa57] (00/236) No matches
 05 [3900408b] (00/236) No matches
 06 [d088dc97] (00/232) No matches
 07 [4dc24a0d] (00/232) No matches
 08 [e002b7ed] (00/230) No matches
 09 [2eed2694] (00/230) No matches
 10 [88c14c8f] (00/226) No matches
 11 [f98cdac7] (00/228) No matches
 12 [ba577135] (00/230) No matches
 13 [b280f684] (00/225) No matches
 14 [b9f028f1] (00/229) No matches
 15 [63334577] (00/224) No matches
 16 [4d14febd] (00/219) No matches
 17 [cf8429c8] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [513a0573] (00/199) No matches
Offsetted by -681:
 01 [819f8dfa] (29/233) Accurately ripped
 02 [6df41e52] (31/236) Accurately ripped
 03 [17f41ef9] (31/236) Accurately ripped
 04 [5302b1f5] (30/236) Accurately ripped
 05 [03f671ec] (31/236) Accurately ripped
 06 [d02ae344] (31/232) Accurately ripped
 07 [2797ed48] (31/232) Accurately ripped
 08 [3f8bc1cb] (30/230) Accurately ripped
 09 [c286a974] (30/230) Accurately ripped
 10 [9f1a4382] (31/226) Accurately ripped
 11 [77c36958] (29/228) Accurately ripped
 12 [d802ded1] (30/230) Accurately ripped
 13 [bb808006] (28/225) Accurately ripped
 14 [fe53b4a7] (30/229) Accurately ripped
 15 [b79e2f61] (30/224) Accurately ripped
 16 [23b8519f] (30/219) Accurately ripped
 17 [8b268f50] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [9deef9a5] (25/199) Accurately ripped
Offsetted by -664:
 01 [9a0bf154] (10/233) Accurately ripped
 02 [6b04050a] (10/236) Accurately ripped
 03 [36388002] (10/236) Accurately ripped
 04 [38f786c4] (10/236) Accurately ripped
 05 [19001e28] (10/236) Accurately ripped
 06 [21cd9f2d] (10/232) Accurately ripped
 07 [ababe751] (10/232) Accurately ripped
 08 [734e15ca] (10/230) Accurately ripped
 09 [733e868d] (10/230) Accurately ripped
 10 [5f487a6d] (10/226) Accurately ripped
 11 [9f1bbb02] (10/228) Accurately ripped
 12 [e0c94f5b] (10/230) Accurately ripped
 13 [e3e4b951] (10/225) Accurately ripped
 14 [68a6faf0] (10/229) Accurately ripped
 15 [f63bfc7b] (10/224) Accurately ripped
 16 [58f546c0] (09/219) Accurately ripped
 17 [9c7b209f] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [f122cac5] (07/199) Accurately ripped
Offsetted by 760:
 01 [8beb03eb] (06/233) Partial match
 02 [ed446133] (06/236) Accurately ripped
 03 [3260126e] (06/236) Accurately ripped
 04 [c40ec9a6] (06/236) Accurately ripped
 05 [451739ed] (06/236) Accurately ripped
 06 [2bdea9dc] (06/232) Accurately ripped
 07 [fb2801c3] (06/232) Accurately ripped
 08 [9011193a] (06/230) Accurately ripped
 09 [439a7be3] (06/230) Accurately ripped
 10 [39daa826] (06/226) Accurately ripped
 11 [490d6594] (06/228) Accurately ripped
 12 [7978cdc2] (05/230) Accurately ripped
 13 [26c39089] (06/225) Accurately ripped
 14 [f548e9f8] (06/229) Accurately ripped
 15 [4a96d80f] (05/224) Accurately ripped
 16 [4e09c7bd] (05/219) Partial match
 17 [fbcaa9b6] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [625e921e] (05/199) Partial match
Offsetted by 872:
 01 [dd639869] (15/233) Accurately ripped
 02 [3f31f6d5] (16/236) Accurately ripped
 03 [b3d7b32b] (15/236) Accurately ripped
 04 [dd915cfe] (15/236) Accurately ripped
 05 [990b68d3] (15/236) Accurately ripped
 06 [a02d3c56] (15/232) Accurately ripped
 07 [cfd60456] (16/232) Accurately ripped
 08 [f4206fca] (15/230) Accurately ripped
 09 [da84947b] (16/230) Accurately ripped
 10 [c3348744] (15/226) Accurately ripped
 11 [011f075e] (14/228) Accurately ripped
 12 [8db0c3ae] (15/230) Accurately ripped
 13 [41a9f043] (15/225) Accurately ripped
 14 [f47f871e] (15/229) Accurately ripped
 15 [6ebdf21a] (15/224) Accurately ripped
 16 [3ddb6353] (14/219) Accurately ripped
 17 [2e0ec70d] (02/17) Accurately ripped
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [7bf9ddc2] (11/199) Accurately ripped
Offsetted by 1427:
 01 [1fbb47f9] (08/233) Partial match
 02 [0b6f9d2b] (08/236) Accurately ripped
 03 [eb8c0bba] (08/236) Accurately ripped
 04 [353f656f] (08/236) Accurately ripped
 05 [f251f9b0] (08/236) Accurately ripped
 06 [6f73d04e] (07/232) Accurately ripped
 07 [a5c9d2b7] (08/232) Accurately ripped
 08 [51ac714f] (08/230) Accurately ripped
 09 [2531f314] (08/230) Accurately ripped
 10 [951e7c9e] (08/226) Accurately ripped
 11 [5822f128] (08/228) Accurately ripped
 12 [5c492651] (08/230) Accurately ripped
 13 [7771265a] (08/225) Accurately ripped
 14 [48394fe3] (08/229) Accurately ripped
 15 [46828872] (07/224) Accurately ripped
 16 [71345b93] (08/219) Partial match
 17 [fced92bf] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [bac2a86f] (07/199) Partial match
Offsetted by 2015:
 01 [f3492269] (02/233) Partial match
 02 [80c531d3] (02/236) Accurately ripped
 03 [54f027e8] (02/236) Accurately ripped
 04 [edc695ec] (02/236) Accurately ripped
 05 [bb2ee106] (02/236) Accurately ripped
 06 [5930e438] (02/232) Accurately ripped
 07 [828d0f5c] (02/232) Accurately ripped
 08 [5efcf7c3] (02/230) Accurately ripped
 09 [1406df21] (02/230) Accurately ripped
 10 [aa50cc96] (02/226) Accurately ripped
 11 [6e95529e] (02/228) Accurately ripped
 12 [f6bf153e] (02/230) Accurately ripped
 13 [8482d80b] (02/225) Accurately ripped
 14 [fd9126a2] (02/229) Accurately ripped
 15 [5fb4d835] (02/224) Accurately ripped
 16 [6a386099] (02/219) Partial match
 17 [7ae3f8d2] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [63586307] (02/199) Partial match
Offsetted by 2086:
 01 [17be47e3] (69/233) Partial match
 02 [41195d37] (69/236) Accurately ripped
 03 [2551de18] (71/236) Accurately ripped
 04 [554aa117] (70/236) Accurately ripped
 05 [9d820193] (70/236) Accurately ripped
 06 [0dd66af8] (69/232) Accurately ripped
 07 [bacc5686] (67/232) Accurately ripped
 08 [5546b0ec] (67/230) Accurately ripped
 09 [1a70a33b] (69/230) Accurately ripped
 10 [565fa4d9] (65/226) Accurately ripped
 11 [11e1f813] (68/228) Accurately ripped
 12 [6e436b40] (69/230) Accurately ripped
 13 [7e58dbe0] (67/225) Accurately ripped
 14 [18368019] (67/229) Accurately ripped
 15 [970c5ea4] (65/224) Accurately ripped
 16 [ee476e21] (62/219) Partial match
 17 [fc300961] (08/17) Accurately ripped
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [06811b15] (62/199) Partial match
Offsetted by 2339:
 01 [53dbdaa2] (02/233) Accurately ripped
 02 [334adc12] (02/236) Accurately ripped
 03 [49551e7a] (02/236) Accurately ripped
 04 [921c879f] (02/236) Accurately ripped
 05 [c7f7ae45] (02/236) Accurately ripped
 06 [487f2340] (02/232) Accurately ripped
 07 [90281100] (02/232) Accurately ripped
 08 [ee2956bf] (02/230) Accurately ripped
 09 [cb13a0a1] (02/230) Accurately ripped
 10 [f8db0b4c] (02/226) Accurately ripped
 11 [75e5e713] (02/228) Accurately ripped
 12 [43ae1737] (02/230) Accurately ripped
 13 [e03d641b] (02/225) Accurately ripped
 14 [7b1c6402] (02/229) Accurately ripped
 15 [51476228] (02/224) Accurately ripped
 16 [ce04fb25] (02/219) Accurately ripped
 17 [1f81bde3] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [0e9b378f] (02/199) Accurately ripped
Offsetted by 2357:
 01 [74671628] (15/233) Accurately ripped
 02 [27908390] (16/236) Accurately ripped
 03 [66a6f3c3] (15/236) Accurately ripped
 04 [d23870d8] (15/236) Accurately ripped
 05 [80379e36] (15/236) Accurately ripped
 06 [7ac52300] (15/232) Accurately ripped
 07 [f0db3f85] (15/232) Accurately ripped
 08 [d9abcdcd] (15/230) Accurately ripped
 09 [efafcbec] (14/230) Accurately ripped
 10 [ba2019af] (14/226) Accurately ripped
 11 [654b0a33] (14/228) Accurately ripped
 12 [8969d345] (14/230) Accurately ripped
 13 [b66616e7] (14/225) Accurately ripped
 14 [7376584e] (15/229) Accurately ripped
 15 [466f08c7] (14/224) Accurately ripped
 16 [375cc1c5] (13/219) Accurately ripped
 17 [f1f09860] (03/17) Accurately ripped
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [42c998b3] (09/199) Accurately ripped
Offsetted by 2369:
 01 [9b448147] (00/233) No matches
 02 [57135899] (00/236) No matches
 03 [6caf398c] (00/236) No matches
 04 [d171a773] (02/236) Accurately ripped
 05 [e347cc46] (00/236) No matches
 06 [8a92025e] (00/232) No matches
 07 [c43d4cdb] (00/232) No matches
 08 [76ad7281] (00/230) No matches
 09 [98d321ba] (00/230) No matches
 10 [a405b51a] (00/226) No matches
 11 [8460d6ae] (00/228) No matches
 12 [f4335489] (00/230) No matches
 13 [dbbec2e1] (00/225) No matches
 14 [aef5aad4] (00/229) No matches
 15 [b25fc542] (00/224) No matches
 16 [e22562ba] (00/219) No matches
 17 [c23ec634] (17/17) Partial match
 18 [00000000] (00/00) No matches
 19 [00000000] (00/00) No matches
 20 [00000000] (01/01) Partial match
 21 [00000000] (00/00) No matches
 22 [00000000] (00/00) No matches
 23 [00000000] (00/00) No matches
 24 [00000000] (00/00) No matches
 25 [00000000] (00/00) No matches
 26 [00000000] (00/00) No matches
 27 [00000000] (00/00) No matches
 28 [00000000] (00/00) No matches
 29 [00000000] (00/00) No matches
 30 [00000000] (00/00) No matches
 31 [00000000] (00/00) No matches
 32 [00000000] (00/00) No matches
 33 [00000000] (00/00) No matches
 34 [00000000] (00/00) No matches
 35 [00000000] (00/00) No matches
 36 [00000000] (01/01) Partial match
 37 [00000000] (00/00) No matches
 38 [00000000] (00/00) No matches
 39 [00000000] (00/00) No matches
 40 [00000000] (00/00) No matches
 41 [00000000] (00/00) No matches
 42 [00000000] (00/00) No matches
 43 [00000000] (00/00) No matches
 44 [00000000] (00/00) No matches
 45 [00000000] (00/00) No matches
 46 [00000000] (00/00) No matches
 47 [00000000] (00/00) No matches
 48 [00000000] (00/00) No matches
 49 [00000000] (00/00) No matches
 50 [00000000] (00/00) No matches
 51 [00000000] (00/00) No matches
 52 [00000000] (00/00) No matches
 53 [00000000] (00/00) No matches
 54 [00000000] (00/00) No matches
 55 [00000000] (00/00) No matches
 56 [00000000] (00/00) No matches
 57 [00000000] (00/00) No matches
 58 [00000000] (00/00) No matches
 59 [00000000] (00/00) No matches
 60 [00000000] (00/00) No matches
 61 [00000000] (00/00) No matches
 62 [00000000] (00/00) No matches
 63 [00000000] (00/00) No matches
 64 [00000000] (00/00) No matches
 65 [00000000] (00/00) No matches
 66 [00000000] (00/00) No matches
 67 [00000000] (00/00) No matches
 68 [00000000] (00/00) No matches
 69 [00000000] (00/00) No matches
 70 [00000000] (00/00) No matches
 71 [00000000] (00/00) No matches
 72 [00000000] (00/00) No matches
 73 [00000000] (00/00) No matches
 74 [00000000] (00/00) No matches
 75 [00000000] (00/00) No matches
 76 [00000000] (00/00) No matches
 77 [00000000] (00/00) No matches
 78 [00000000] (00/00) No matches
 79 [00000000] (00/00) No matches
 80 [00000000] (00/00) No matches
 81 [00000000] (00/00) No matches
 82 [00000000] (00/00) No matches
 83 [00000000] (00/00) No matches
 84 [00000000] (00/00) No matches
 85 [00000000] (00/00) No matches
 86 [00000000] (00/00) No matches
 87 [00000000] (00/00) No matches
 88 [00000000] (00/00) No matches
 89 [00000000] (00/00) No matches
 90 [00000000] (00/00) No matches
 91 [00000000] (00/00) No matches
 92 [00000000] (00/00) No matches
 93 [00000000] (00/00) No matches
 94 [00000000] (00/00) No matches
 95 [00000000] (00/00) No matches
 96 [00000000] (00/00) No matches
 97 [00000000] (00/00) No matches
 98 [00000000] (00/00) No matches
 99 [65932ecb] (00/199) No matches

Track [ CRC32  ] [W/O NULL]
 -- [8DFCE543] [C1843DC7]
 01 [6E92FC4E] [48268136]
 02 [9F44ABAB] [82640D64]
 03 [06EA5868] [C35DD86F]
 04 [78556267] [2AE7FD72]
 05 [7ADFA01B] [B99BDBA4]
 06 [8813D7C6] [0B07FFBD]
 07 [7EC72AF0] [E4003279]
 08 [9CF0092B] [2056A58A]
 09 [BFCF1CA8] [8A674008]
 10 [2D24E227] [1469E6AD]
 11 [D6E9C8C4] [1D707D2F]
 12 [E31E2909] [A3B4F359]
 13 [D506A265] [18DC6E60]
 14 [5F03E5AA] [BC30712B]
 15 [184635CB] [375570FA]
 16 [FC022D76] [75A27F67]
 17 [A180A5B8] [B5641F62]
 18 [02864C0E] [00000000] W/O NULL
 19 [02864C0E] [00000000] W/O NULL
 20 [02864C0E] [00000000] W/O NULL
 21 [02864C0E] [00000000] W/O NULL
 22 [02864C0E] [00000000] W/O NULL
 23 [02864C0E] [00000000] W/O NULL
 24 [02864C0E] [00000000] W/O NULL
 25 [02864C0E] [00000000] W/O NULL
 26 [02864C0E] [00000000] W/O NULL
 27 [02864C0E] [00000000] W/O NULL
 28 [02864C0E] [00000000] W/O NULL
 29 [02864C0E] [00000000] W/O NULL
 30 [02864C0E] [00000000] W/O NULL
 31 [02864C0E] [00000000] W/O NULL
 32 [02864C0E] [00000000] W/O NULL
 33 [02864C0E] [00000000] W/O NULL
 34 [02864C0E] [00000000] W/O NULL
 35 [02864C0E] [00000000] W/O NULL
 36 [02864C0E] [00000000] W/O NULL
 37 [02864C0E] [00000000] W/O NULL
 38 [02864C0E] [00000000] W/O NULL
 39 [02864C0E] [00000000] W/O NULL
 40 [02864C0E] [00000000] W/O NULL
 41 [02864C0E] [00000000] W/O NULL
 42 [02864C0E] [00000000] W/O NULL
 43 [02864C0E] [00000000] W/O NULL
 44 [02864C0E] [00000000] W/O NULL
 45 [02864C0E] [00000000] W/O NULL
 46 [02864C0E] [00000000] W/O NULL
 47 [02864C0E] [00000000] W/O NULL
 48 [02864C0E] [00000000] W/O NULL
 49 [02864C0E] [00000000] W/O NULL
 50 [02864C0E] [00000000] W/O NULL
 51 [02864C0E] [00000000] W/O NULL
 52 [02864C0E] [00000000] W/O NULL
 53 [02864C0E] [00000000] W/O NULL
 54 [02864C0E] [00000000] W/O NULL
 55 [02864C0E] [00000000] W/O NULL
 56 [02864C0E] [00000000] W/O NULL
 57 [02864C0E] [00000000] W/O NULL
 58 [02864C0E] [00000000] W/O NULL
 59 [02864C0E] [00000000] W/O NULL
 60 [02864C0E] [00000000] W/O NULL
 61 [02864C0E] [00000000] W/O NULL
 62 [02864C0E] [00000000] W/O NULL
 63 [02864C0E] [00000000] W/O NULL
 64 [02864C0E] [00000000] W/O NULL
 65 [02864C0E] [00000000] W/O NULL
 66 [02864C0E] [00000000] W/O NULL
 67 [02864C0E] [00000000] W/O NULL
 68 [02864C0E] [00000000] W/O NULL
 69 [02864C0E] [00000000] W/O NULL
 70 [02864C0E] [00000000] W/O NULL
 71 [02864C0E] [00000000] W/O NULL
 72 [02864C0E] [00000000] W/O NULL
 73 [02864C0E] [00000000] W/O NULL
 74 [02864C0E] [00000000] W/O NULL
 75 [02864C0E] [00000000] W/O NULL
 76 [02864C0E] [00000000] W/O NULL
 77 [02864C0E] [00000000] W/O NULL
 78 [02864C0E] [00000000] W/O NULL
 79 [02864C0E] [00000000] W/O NULL
 80 [02864C0E] [00000000] W/O NULL
 81 [02864C0E] [00000000] W/O NULL
 82 [02864C0E] [00000000] W/O NULL
 83 [02864C0E] [00000000] W/O NULL
 84 [02864C0E] [00000000] W/O NULL
 85 [02864C0E] [00000000] W/O NULL
 86 [02864C0E] [00000000] W/O NULL
 87 [02864C0E] [00000000] W/O NULL
 88 [02864C0E] [00000000] W/O NULL
 89 [02864C0E] [00000000] W/O NULL
 90 [02864C0E] [00000000] W/O NULL
 91 [02864C0E] [00000000] W/O NULL
 92 [02864C0E] [00000000] W/O NULL
 93 [02864C0E] [00000000] W/O NULL
 94 [02864C0E] [00000000] W/O NULL
 95 [02864C0E] [00000000] W/O NULL
 96 [02864C0E] [00000000] W/O NULL
 97 [02864C0E] [00000000] W/O NULL
 98 [79914BAF] [00000000] W/O NULL
 99 [823FBB6A] [2A15BCBE]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-09-04 19:47:31
The database has entries for those tracks. I assume in someone's rip they were not entirely silent due to ripping errors.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-09-04 20:01:59
Thks, I didn't thought about this possibility, at first it's quite funny to think that scratches produces ghost tracks  ... but then it's annoying as even if future cuetools version reports empty tracks as accurate, my rip will not be reported as accurate... Is there anyway Spoon can purge such results ? Wouldn't something like keeping record for empty tracks & purge ghost tracks if 99% of silence tracks disagree with a lone non-silence track help ? I mean it should be possible to purge such results if the database would keep track of silence tracks but I don't think it does, does it ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: swolf on 2009-09-05 05:02:19
CUETools is great, thanks so much for this!

Suggestion: for none output, allow it to convert even if original files aren't there.


Edit: I get "Could not load file or assembly 'CUETools.Codecs.TTA" for 2.0.4a, and I installed the vcredist_x86.exe already, any other reasons this should happen?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-09-09 19:30:05
When I encode corrected offsets tracks CUETools rightly informs me that some samples are going to be lost:
Quote
Write offset settings is non-zero which will cause some samples to be discarded.

If I verify the generated tracks with AccurateRipDB and all the tracks are 100% accurate (with high confidence), can I say I have the perfect copy of the disc, even if there are lost samples and new empty samples created by the offset correction?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fuki on 2009-09-10 14:08:00
When I encode corrected offsets tracks CUETools rightly informs me that some samples are going to be lost:
Quote
Write offset settings is non-zero which will cause some samples to be discarded.

If I verify the generated tracks with AccurateRipDB and all the tracks are 100% accurate (with high confidence), can I say I have the perfect copy of the disc, even if there are lost samples and new empty samples created by the offset correction?

Yes, because the "discarded samples" are most probably zeros.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-09-10 14:33:56
If 100% of tracks are Accurate with confidency 2 on the same target offset then it is not a probability it is a certainty, because the all the CRC match with the target pressing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2009-09-10 18:21:28
Gregory, are there any plans to implement multi-threaded processing? Multi-threaded decode/verify and multi-threaded encode?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-09-10 18:43:37
As far as I understund real multi-threading as nothing to do with cuetools, it must be supported in the external command line for cuetools to support it. Like F2K there can be the trick to launch several tracks at once, but the purpose of cuetools is to work on whole albums so it's the opposite of its philosophy IMHO. Furthermore it may be (I dunno & I'm guessing) a real headache to code with non-silence offset which affect the split point. People buying quad core should wonder why they buy a quad core before buying. Instead of annoying every developper with multithreading ... that's the exact reason why I won't buy a Core I5 but I am waiting for Core I3. For the same price, I'd rather buy a Core I3 & a SSD than a Core I5 alone ... the only multithreaded software I use is x264.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: swolf on 2009-09-11 07:13:07
OK I've solved my problem.

I have only 1 question about CUETools now. If I'm splitting a CUE with a 30 second pre-gap, as shown below, is there any way to have it put "PREGAP" in the resulting CUE sheet as EAC would, rather than make an extra 30 second file [of silence] called HTOA, as CUETools keeps doing?

...
FILE "Mind~Flux - Body-Beat-Box.ape" WAVE
  TRACK 01 AUDIO
    TITLE "Warm-Up"
    PERFORMER "Mind Flux"
    INDEX 00 00:00:00
    INDEX 01 00:00:30
...

Thanks...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: juest on 2009-09-11 11:42:53
I don't know about anyone else, but I'm not really liking the new interface in the latest version (and versions after 2.0.2a). I've tried really hard to adjust to it, but it just looks and feels too awkward. Version 2.0.2a matches my preferences perfectly, and it has all the qualities of a simple, minimal application. All the important features are all located in the main window, none of them disappearing or reappearing when choosing different options, and it just simply performs more like a standard Windows application. I would never assume 2.0.2a was developed with .NET just by using it, however with the newer versions, it's far too apparent.

Some requests:

I normally don't do batch jobs and just convert albums one at a time when I need to, and I would very much prefer to have some sort of a Browse... button that would open up a general Open window such as the one below. Sometimes I want to be able to manually type in the location of the folder, instead of having to search through and click multiple tick boxes.

(http://img6.imageshack.us/img6/3282/openwindowu.jpg)

Also, I noticed the option to place converted files in a subfolder has been removed in later versions. Could that option be put back in? I usually have an Explorer window open where the original files are stored while CUETools is converting, and it's convenient to have the converted files located near the original files.

(http://img143.imageshack.us/img143/2378/betterg.jpg)


Thank you
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: boyblue on 2009-09-11 18:52:42
i have a album in ape files that i am trying to convert flac files,everytime i try to use CUETools, i insert the cdimage cue file & it says unsupprted audio type.
can a expert of the CUETools program please advise me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-09-11 22:04:23
i have a album in ape files that i am trying to convert flac files,everytime i try to use CUETools, i insert the cdimage cue file & it says unsupprted audio type.
can a expert of the CUETools program please advise me.

Could be single channel files instead of the normal 2 channel files.
Some people convert songs in mono to one channel with p.e. adobe audition or audacity.
If that is the case cuetools gives also that kind of error.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-09-11 22:11:22
Sometimes I want to be able to manually type in the location of the folder, instead of having to search through and click multiple tick boxes.


I usually have an Explorer window open where the original files are stored while CUETools is converting, and it's convenient to have the converted files located near the original files.


If you have an explorer window open, why don't you drag 'n drop the directories?
I always have an explorer window open and imho drag'n drop is much faster then any browse window.

I like the lay-out very much (only problem is the overwrite warning of logfiles I would like to get rid of)

Also, I noticed the option to place converted files in a subfolder has been removed in later versions. Could that option be put back in? I usually have an Explorer window open where the original files are stored while CUETools is converting, and it's convenient to have the converted files located near the original files.


This option is still there: use the template pull down menu and choose: [%directoryname%\]new[%unique%]\%filename%.cue
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2009-09-17 17:45:06
I have been using cuetools since 1.9.5a and I like the new UI layout very much.
I run windows XP in 1440x900 with a custom DPI setting of 115% (110 dpi) and most of the
UI problems are gone with this version and the ones left have been documented (thanks sauvage78  ).

I have used cuetools only to create flac files but today I created alac files for the first time
(using ffmpeg svn 19874) and cuetools did not write accuraterip tags to the alac files (using the same options as flac).
Is there an additional parameter that I am missing ? thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2009-09-19 10:36:43
I created alac files for the first time (using ffmpeg svn 19874) and cuetools did not write accuraterip tags to the alac files (using the same options as flac).
Is there an additional parameter that I am missing ? thanks.

I have tested the buitin encoders (flac, ape) and some additional external encoders (lame, Nero). The external ones don't seem to write accuraterip tags, so I am guessing this is a limitation of the external encoders ?

cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2009-09-20 23:29:17
Hello, Thanks a lot for this wonderful tool.

I have tried the latest, but found it's gui to be too 'basic'/confusing,
& the foobar type variables are unknown to me so I settled on CUETOOLS 2.01.
-Are there any drawbacks to using v 2.01, reliability / Format Wise?
Also, Can I Define a PROXY somewhere so I can use it with a proxy from a non internet connected PC?

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: patmcg on 2009-09-21 05:24:14
Instead of annoying every developper with multithreading ... that's the exact reason why I won't buy a Core I5 but I am waiting for Core I3. For the same price, I'd rather buy a Core I3 & a SSD than a Core I5 alone ... the only multithreaded software I use is x264.

It's been almost 4 years since the first Intel dual-core part. I don't think multi-core architecture is going away, and only going to become more and more critical to software design in the future.

I'm sure a lot of people had the same feelings when graphical desktop environments started becoming popular, and all the programs had to be changed to support Windows or X11. At this point, not designing for multi-core is a sure way for your program to become obsolete relatively quickly.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-09-21 05:37:31
Well indeed heavy multi-threading is the future, but what I meant is that actually a lightly overclocked 32mn dual core will beat a basic 45mn quad core for the same heat & power consumption (or be very near). [for exemple lighly overclocked Core I3 530 Vs basic Athlon II X4 620] So in the end, multi-threading is only really great if you already own a quad-core, if you don't there is no need to hurry buying a quad-core. Multi-threading will come naturally to developper when quad-core will swallow the low end CPU market, which will happen very soon.

Don't get me wrong I would love a multi-threaded Cuetools, it's just that I think that there is more important missing features to code in Cuetools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2009-09-21 22:11:49
i have a album in ape files that i am trying to convert flac files,everytime i try to use CUETools, i insert the cdimage cue file & it says unsupprted audio type.
can a expert of the CUETools program please advise me.


If I had to gamble, I would say you attempted feeding cuetools with a 48 khz file or similar, ie not a 16 bit 44.1 file, check the files audio properties.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2009-09-29 14:25:35
CUEtools 2.0.4a.
APE encoding profiles are "shifted": fast says "Exception: Invalid compression mode", "normal" setting actually produces fast, high - normal, extra high - high, insane - extra high.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hacker1208cb on 2009-10-02 22:47:05
I've run into a bug when generating a cue sheet from a set of flac files.

I'm working off a Samba 3.0.x share mounted as a drive. When I generate a cue sheet on this share, the files appear out of order in the cue sheet I have to sort it manually. This problem does not occur on a local hard drive.

I've traced the problem to the ScanFolder method in the CUESheet class in CUETools.processor\Processor.cs. This method relies on the files parameter to be a sorted IEnumerable. However, the System.IO.DirectoryInfo.GetFileSystemInfos() method used to generated this IEnumerable does not guarantee sorting. This means ScanFolder needs to sort the files first.

The following fixes the problem for me:

Code: [Select]
diff --git a/CUETools.Processor/Processor.cs b/CUETools.Processor/Processor.cs
index 6b91342..54ce9c4 100644
--- a/CUETools.Processor/Processor.cs
+++ b/CUETools.Processor/Processor.cs
@@ -4847,6 +4847,18 @@ return processor.Go();
  }
  }
 
+ public static int CompareFileSystemInfo(FileSystemInfo x, FileSystemInfo y)
+ {
+ return x.Name.CompareTo(y.Name);
+ }
+
+ public static IEnumerable<FileSystemInfo> SortFiles(IEnumerable<FileSystemInfo> files)
+ {
+ List<FileSystemInfo> sortedFiles = new List<FileSystemInfo>(files);
+ sortedFiles.Sort(CompareFileSystemInfo);
+ return sortedFiles;
+ }
+
  public static List<FileGroupInfo> ScanFolder(CUEConfig _config, string path)
  {
  DirectoryInfo dir = new DirectoryInfo(path);
@@ -4856,6 +4868,7 @@ return processor.Go();
  public static List<FileGroupInfo> ScanFolder(CUEConfig _config, IEnumerable<FileSystemInfo> files)
  {
  List<FileGroupInfo> fileGroups = new List<FileGroupInfo>();
+ files = SortFiles(files);
  foreach (FileSystemInfo file in files)
  {
  if ((file.Attributes & FileAttributes.Hidden) != 0)

This problem also showed up in the Folder browser and Multiselect browser, and this change fixes those also.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: markanini on 2009-10-03 05:05:51
Thanks for the great program, It has saved lots of time for me!
Would you consider adding HDCD checking functionallity via the HDCD software decoder? Would be usefull for silent HDCDs like Mahavishnu Orchestra - The Lost Trident Sessions and titles with no peak extension.
Here's the location of the HDCD software decoder/excutable/API http://www.srcf.ucam.org/~cjk32/hdcd/ (http://www.srcf.ucam.org/~cjk32/hdcd/)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-10-03 14:43:04
APE encoding profiles are "shifted"

Thank you.

This problem also showed up in the Folder browser and Multiselect browser, and this change fixes those also.

Thanks a lot for the patch.

Would you consider adding HDCD checking functionallity via the HDCD software decoder?

It's already there, since 1.9.5 or even earlier.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-10-03 14:52:20
& the foobar type variables are unknown to me so I settled on CUETOOLS 2.01.
-Are there any drawbacks to using v 2.01, reliability / Format Wise?
Also, Can I Define a PROXY somewhere so I can use it with a proxy from a non internet connected PC?

Foobar-type variables are documented here: http://www.cuetools.net/doku.php/cuetools:template (http://www.cuetools.net/doku.php/cuetools:template)
2.0.1 mostly differs in GUI, so for now it is perfectly usable if it suits you.
Proxies are not supported at the moment, sorry

As every change in GUI requested by some users is often disappointing for others,
would be nice if we have alternative GUI's available.
If you are familiar with C#, you are welcome to contribute your version of GUI to the project.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: markanini on 2009-10-04 03:05:23
Would you consider adding HDCD checking functionallity via the HDCD software decoder?

It's already there, since 1.9.5 or even earlier.

So it does! I was using a quite ancient version...
I have a request still, under hdcd options, ignore if peak extend if unemployed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: kerpondile on 2009-10-05 19:30:28
I have many rips that have correct cues but the log files don't contain the gap information, so I'm wondering...

Is possibile to copy "pregap" lengths from noncompliant cue to EAC log txt-file using CUETools or some other tool?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2009-10-11 12:41:02
Gregory S. Chudov, i tried to verify rip (CueTools 2.0.4) via command:
i.e.
Quote
"d:\Progs\CUETools\CUETools.exe" /verify "e:\Music\Anata\2006 - The Conductor's Departure\Anata - 2006 - The Conductors Departure.cue"
and i get such error:
Quote
Processing e:\Music\Anata\2006 - The Conductor's Departure\Anata - 2006 - The Conductors Departure.cue:
Error: Object reference not set to an instance of an object.
----------------------------------------------------------

AFAIR, this thing was working on the previous versions.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: isidro on 2009-10-12 07:43:52
great program, in 2.04a version, I think I found a small bug, when generating one WAV file (From Flacs), and use %C as filename, instead of giving the disc name it makes a: "%C.WAV" file (works fine but it's not what intended...)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2009-10-16 20:29:19
I just tested CUETools in Microsoft's FxCop tool. You should do the same. 

http://img194.imageshack.us/img194/7767/mi...opmyfxcoppr.png (http://img194.imageshack.us/img194/7767/microsoftfxcopmyfxcoppr.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BlueDragon on 2009-10-18 02:27:54
@Gregory First of all thank you for working on and developing CueTools as it's functionality is something which is really missing amongst the presently available audio tools.   

As a suggestion would it be an idea to start a new thread? This one is becoming very (to) long and and even a little out of scope since I am trying v2.0.4a. Besides I did not find a way to search effectively within the dozen of pages... So if this has already been asked / discussed please excuse me.

It would be a nice additional feature to have the replay gain tags calculated and added upon encoding (in flac at least). Would that be possible without to much work? Do you plan it?

Thanks again for the good work!! 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: kerpondile on 2009-10-18 17:23:58
Would it be possible to change the "search pattern" for the log and cue files?

My cue files are names as something like "cuesheet.txt" and logs as "EACLog.txt". I'd like to see an option to set  "log filename" and "cuesheet filename" to these filenames, instead of changing my filenames.

-kerpondile
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-10-19 07:13:59
i'd like to request a simple new feature --

when you're in something like folder browse mode, and you click on a file/dir that already has an accurip file in it, could you display the existing one in the output window? a lot of times it will say one already exists, do you want to overwrite it.. then i'm like hmm... then i have to go out to explorer and look at that accurip file and see what it says so i can compare to the re-test.

just would make things a lot more simple, i think.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BlueDragon on 2009-10-20 19:04:35
@Chinch

This would be the "Deluxe" Solution but maybe a simplier one (to implement) would be an optional renaming of the newly created .accurip file, say a sort of [%unique%] option, instead of having only the option to overwrite it or to cancel the action...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-10-20 22:22:50
@Chinch

This would be the "Deluxe" Solution but maybe a simplier one (to implement) would be an optional renaming of the newly created .accurip file, say a sort of [%unique%] option, instead of having only the option to overwrite it or to cancel the action...


yeah.... and/or both. i mean as far as programming goes.. command to check if the file exists..  if it does, load it into the textbox, and maybe ask if we want to regen it... then pop up a dialog that gives options such as...
[create new]  [overwrite existing]  [do not regen]

just an idea. or as you said.. add maybe some foobar tags to append like a date/time or make the filename++ to they're sequentially numbered.

the main 'problem' i was trying to address was that i wanted to view the file in the log window if one exists in the dir already... that way i can look at it, then decide if i want to regen/refresh the results, or use it as a reference to see
if the numbers change any after the second check... then your idea could also be implemented as well.. since they're not mutually exclusive by any means

this way i don't hit GO then it says one exists already, overwrite or not... then i go ah crap... then i gotta open explorer, navigate 4-5 directory levels, find the file and open it to view the old file before i regenerate a new one, then going oh yeah,
i did this way back in january, or oh wait, i just did this one last night... that sort of thing.

as said.. i think as far as the amount/complexity of code  to accomplish this small task is only a few lines of code, but would make the program much more useful.
come to think of it... it's open source.. so technically i could probably just make the customizations myself... he has already done the hard part of the code.. the rest is just customizations and optimizations.

i wonder if sir chudov the great is still working on CUEtools.. haven't seen a release in a bit.. but last i saw he had a few side projects.. including a lot of flake optimizations.. and even experimenting with using CUDA in encoding FLAC... his project "flacuda". very interesting, and looks like he's making some progress there. lucky for me, I have a CUDA supported card, so I'll give it a try when I can, just to see the potential if nothing else...

i'd love to see full multicore support in more programs these days... especially encoding/analysis ones, where encoding time is a big problem still... be it audio or video. dual core is pretty much standard these days, and people like me who have Intel i7's... that's 4 cores, plus hyperthreading, so a total of 8 virtual processors. then chudov is doing things further by using CUDA... i imagine a program coded to utilize 64-bit w/ multiple cores paired with CUDA support... it would have to scream.

i'm no master of it all, but i say if you've got the power.. use it.

(btw, for anyone who doesn't know what CUDA is.. it's basically an technology developed by Nvidia that allows you to use your graphics card processor(s) to handle tasks as the CPU would.. except graphics cards have capabilities of running a ton of threads in parallel)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vomitus on 2009-10-25 20:42:51
I apologize if this was already spoken about and I didn't find it but how can I embed cue sheet into flac file without re-encoding it? Usually I use foobar for this but lately some certain flac and cue files seem to make foobar process them incorrectly. Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-10-25 20:50:44
I apologize if this was already spoken about and I didn't find it but how can I embed cue sheet into flac file without re-encoding it? Usually I use foobar for this but lately some certain flac and cue files seem to make foobar process them incorrectly. Thanks.


that's normally how i do it, through foobar2000. if you want to re-add or update a cue sheet, you can right click on a track after loading a FLAC file with an embedded cue, then go Utils -> Edit Cue sheet... I would uncheck the "Allow embedded cue sheet" and click OK to remove the old one, or simply reload with the new one.

i am willing to bet your problem with foobar is that the cue sheets keep changing from what you originally put in the box, right? If this is what you are experiencing, the problem lies in the tags of the files. For whatever reason, foobar updates the CUE info based on TAG info, not the other way around. So if you go into the Properties/Tag screen, you need to change the values you want there, which will update the embedded CUE sheet... otherwise it will keep overwriting any changes you make to the CUE itself.

for instance, if you go in to edit the embedded cue and change the TRACK line from "somthing" to "something", hit OK, then go back into the cue.. it'll be back at "somthing"! once you edit the tag to reflect the name, it'll automatically change the CUE file for you... so just remember that -> Tag data overrides embedded CUE data ... at least as of the current version.

hope that helps you with the problem. i ran into this same issue and it confused the heck out of me cause i couldn't figure out why it wasn't updating properly, until I happened to randomly realize that the Tags were still wrong after a CUE update and put 2 and 2 together.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: leland on 2009-10-25 22:01:07
looks very cool, there's a bit of a UI bug that i've come across. if your dpi is set at anything other than 100% it appears that you're unable to resize windows to see all the UI options... i'm unable to change the size of the program to see what I might be missing...

see my picture:
(http://img18.imageshack.us/img18/773/cuetools.jpg)

in any event, i'm glad i found this as i'm hoping that i can use this to clean up some old .ape+.cue files to be single-track flac albums (not sure how many devices / players support embedded flac cues, so if i should change my strategy please reply or pm me w/ a link).

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vomitus on 2009-10-26 04:17:51
Chinch
The problem with foobar I am talking about is that when you select an empty(i meant without tags) .flac file(which is a whole album) and trying to add a cue sheet from Utils -> Edit cue sheet menu. On Edit cue sheet screen I load external cue file and it's content is displayed in that window. When I press OK, cue sheet embeds into file. But When I open that file with foobar again it has all tracks with the same name! And this name is(what is strange btw) the title of the 2nd track from the external cue.
Using CUETools with re-encoding solved a problem but it is quite a time to wait. Suggestions?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-10-26 05:36:59
Chinch
The problem with foobar I am talking about is that when you select an empty(i meant without tags) .flac file(which is a whole album) and trying to add a cue sheet from Utils -> Edit cue sheet menu. On Edit cue sheet screen I load external cue file and it's content is displayed in that window. When I press OK, cue sheet embeds into file. But When I open that file with foobar again it has all tracks with the same name! And this name is(what is strange btw) the title of the 2nd track from the external cue.
Using CUETools with re-encoding solved a problem but it is quite a time to wait. Suggestions?


ah yes.. i had a similar problem where all of the files had the same title....... gah what was the problem there... it had to do with .... .... man. i wish i could think of it right now.. my mind is drained from work and i'm sleepy.... gimme until tomorrow and i'll remember when my mind is fresh.

question: how are you ripping, ... single wav + cue, multiple tracks+cue... ? also what program are you ripping with. it seems to me that if the filename(s) in the cue file can't be found, it will use the first track over and over. man. i wish i could remember what was causing that right now...  but just FYI, i use EAC to rip single wav+cue, then i encode the WAV -> FLAC using the flac encoder, then i open the single flac file and embed the cue.

here is an example for reference, of a working embedded cue file .. randomly picked:

Code: [Select]
REM GENRE Metal
REM DATE 1991
REM DISCID AC0EAD0C
REM COMMENT ExactAudioCopy v0.99pb5
CATALOG 0075596111321
PERFORMER "Metallica"
TITLE "Metallica"
REM REPLAYGAIN_ALBUM_GAIN -6.11 dB
REM REPLAYGAIN_ALBUM_PEAK 0.999969
FILE "Metallica - Metallica.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Enter Sandman"
    REM REPLAYGAIN_TRACK_GAIN -5.45 dB
    REM REPLAYGAIN_TRACK_PEAK 0.999969
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    TITLE "Sad But True"
    REM REPLAYGAIN_TRACK_GAIN -6.20 dB
    REM REPLAYGAIN_TRACK_PEAK 0.999969
    INDEX 00 05:31:62
    INDEX 01 05:32:00
  TRACK 03 AUDIO
    TITLE "Holier Than Thou"
    REM REPLAYGAIN_TRACK_GAIN -7.34 dB
    REM REPLAYGAIN_TRACK_PEAK 0.999969
    INDEX 00 10:56:05
    INDEX 01 10:56:42

etc....


now, you will notice that the file showing in the cue sheet is a .WAV file.... FILE "Metallica - Metallica.wav" WAVE
it is the original cue sheet that i embedded, unmodified. The WAV file it references is not physically there, but a FLAC file with the identical name is there, "Metallica - Metallica.flac", which this is embedded into.
i'm not sure why it works if the file doesn't exist, but it seems as if i renamed it to .FLAC it screwed up? show me some examples and we can work with it...

don't know if that helps any. i will remember for you and we will see once i get a little more info from you...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2009-10-27 07:54:52
I apologize if this was already spoken about and I didn't find it but how can I embed cue sheet into flac file without re-encoding it? Usually I use foobar for this but lately some certain flac and cue files seem to make foobar process them incorrectly. Thanks.

CUE files can be embedded into FLAC images as CUESHEET block-types and/or CUESHEET tags.
Use metaflac command line tool (more info here (http://flac.sourceforge.net/documentation_tools_metaflac.html)) like this:

1) embedded/extract as CUESHEET block-type:
metaflac --import-cuesheet-from=file.cue file.flac
metaflac --list --block-type=CUESHEET file.flac > file.cue

2) embedded/extract as CUESHEET tag:
metaflac --set-tag-from-file=CUESHEET=file.cue file.flac
metaflac --show-tag=CUESHEET file.flac > file.cue

You can also use mp3tag for CUESHEET tags.

cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dirki on 2009-10-31 22:50:01
How can I set this format when encoding using a cue sheet:

Input:
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep.cue

Output:
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep (1987)\01. In The Name Of Money.wav
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep (1987)\02. Time Out.wav
...

Nice greetings, Dirk
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dirki on 2009-10-31 22:54:54
How can I store my own settings (the file containing the settings) in a folder of my choice, e.g. in H:\Musik (original)?

Nice greetings, Dirk
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dirki on 2009-10-31 23:24:47
How can I open Cue-Tools with always the same profile? It always seems to start with the "default" profile, instead of the one which was opened when I closed Cue-Tools.

Nice greetings, Dirk
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vomitus on 2009-11-01 06:56:05
I was trying to embed cue sheet with reencoding source into flac file and found these two possible bugs:
1. When encoding with internal flac encoder it utilizes only 1 core of dual-core processor. However, standalone flac encoder uses both cores (which in fact speeds up encoding process up to 40%).
2. One of created flacs this way was kinda broken: I was unable to add ReplayGain info into it using foobar("Could not update tags (Unsupported format or corrupted file)" was the message). However, if reencoded with standalone flac encoder, this bug was disappeared.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dirki on 2009-11-01 09:49:13
How can I set this format when encoding using a cue sheet:

Input:
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep.cue

Output:
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep (1987)\01. In The Name Of Money.wav
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep (1987)\02. Time Out.wav
...

Nice greetings, Dirk


And I tried this template:
[%directoryname%\]%artist% - %album% %year%[%unique%]\%filename%.cue
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-11-01 23:53:56
I was trying to embed cue sheet with reencoding source into flac file and found these two possible bugs:
1. When encoding with internal flac encoder it utilizes only 1 core of dual-core processor. However, standalone flac encoder uses both cores (which in fact speeds up encoding process up to 40%).
2. One of created flacs this way was kinda broken: I was unable to add ReplayGain info into it using foobar("Could not update tags (Unsupported format or corrupted file)" was the message). However, if reencoded with standalone flac encoder, this bug was disappeared.


From what I believe, there are two different FLAC encoders possible to use in CUETools... that is FLACLib and flake. One is obviously the "original" flac encoder library, the other is made by someone else... (chudov, maybe? i am not sure). i know he was making some changes with it. is it possible that the alternate one is selected? also you may check the options for these encoders under the 'encoders' tag in the options. to make sure everything is how you want it.

ultimately, it sounds like some non-standard stuff is going on. here is the method I personally use,when ripping original CD's... may be a little longer, but doesn't really bother me:
1) rip with EAC -- test & copy, create image w/ cue
2) go into FLAC frontend (the one that comes with the FLAC codec pack) and encode mine using only compression 8 and 'verify' checked. (compression/decompression speed is not a factor for me, i have a very fast machine) i do not embed the cuesheet here.
3) go into foobar, add the single FLAC file to the queue, then embed the cue file inside of foobar. i have to close the program out and re-open it, or remove/re-add the FLAC file for it to actually show the tracks split out and tagged (is there a quicker way to do this? i tried reload tags/info... didn't work)

yes, i know i could actually combine step 1 and 2, it's just half a second longer. though, i'm not sure if it keeps the original WAV file when you use the encoder option in EAC. I'll have to check that out. can't remember.

Either way, I have had nothing but success with this, never a single problem. not to say there is anything wrong with CUETools, as I haven't really used the transcoding feature but once or twice, i use it primarily for its VERIFY function... I do all of my splitting/transcoding/decoding/cuesheet&tagging, etc in foobar2000. still, CUETools is a great program and I couldn't do without it.


so i ask again, what format are your original files in (codec).... and are they single file or file-per-track?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vomitus on 2009-11-02 02:10:12
From what I believe, there are two different FLAC encoders possible to use in CUETools... that is FLACLib and flake. One is obviously the "original" flac encoder library, the other is made by someone else... (chudov, maybe? i am not sure). i know he was making some changes with it. is it possible that the alternate one is selected? also you may check the options for these encoders under the 'encoders' tag in the options. to make sure everything is how you want it.

I use 1.9.5a version and it has no flake as I believe. And the only option there is encoding level and 'verify' checkbox. What concerning 2.xx versions - its interface just overwhelmed me(it is too alpha to use it and it requires huge reconsideration, but that another story). I can't test now on 2.x version because I already have no source, but the source was single flac file with less compression level.
Well, I post here not to solve my personal problem but make developer to be aware of possible bugs. Concerning multicore CPU load it seems it's a problem of original flac encoder, because it often uses only one core too. But the problem with "corrupted" resulting flac file? This one confuses me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-02 19:38:24
Hello!

Can someone please give me an exact explanation of these tag fields written by CUETools?

<ACCURATERIPCOUNT> : 2
<ACCURATERIPCOUNTALLOFFSETS> : «multiple values» 273; 272; 270
<ACCURATERIPCOUNTWITHOFFSET> : «multiple values» 139; 137; 136; 138
<ACCURATERIPOFFSET> : +688
<ACCURATERIPTOTAL> : «multiple values» 273; 272; 270

What actually indicates that I have an accurate copy?

One more question:

Assuming I had only the tracks of an album without the original cue file. When I now compress it to a single WavPack file using CUETools it tells me my copy is accurate and embeds a dummy cuesheet. Is there any difference to the cuesheet file EAC would have created during ripping?

As long as CUETools tells me its accurate there is actually no need to keep external cue/log files, right?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-11-02 20:37:03
I would compare the tags against the output of the program.. both in normal and verbose mode... that way you can more clearly see what values mean what. Could you post the output for this in compact (non verbose) mode? We could probably clarify much easier.

As far as the cue sheet goes, yes there are differences in the dummy cue sheet vs. a normal one. for instance, (I'm not sure exactly how Mr. Chudov creates the "dummy" cue files), but I would imagine that they are simply as implied.. fully generic cue files, just enough info to comply to the CUE standards. for instance, some things it may be missing vs. an EAC cue file could be optional entries such as ISRC codes, possibly pregap or an entry for any data previous to the first track... it may all be based on 00:00 indexing.. these are all assumptions as I tried against a FLAC file with embedded cue, and it pulled the correct cue from the internal FLAC data, as it should. I tried extracting to a single WAV file, then creating a cue file, but it seems to be greyed out and won't allow me to do it. I'm assuming since they are not multiple tracks with their own song titles, etc... it does not know where to get the number of tracks, each track's length, etc... so it would be pretty difficult to determine what it actually was, without any information, especially since WAV format does not support tagging... if you ONLY had a single WAV file, I would assume that the only way it could be matched against anything was an MD5 or better yet, SHA-1 checksum of the WAV file itself.

(Although if you had the corresponding LOG file with TOC data in it, it could feasibly be parsed)

Hope you get what I'm saying... if not let us know.. maybe someone else can explain in their own terms as well, or the author can extrapolate and/or clarify the answer to your question.

edit: in re-reading your post, i see that you are compressing to WAVpak... and to be honest, I'm not entirely familiar with it, other than it is one of the many codecs available to compress audio. not sure what tagging it uses (id3, vorbis, etc). but personally, i *always* keep the original CUE and LOG files, regardless if they are embedded or not. who is to say the tag may one day be damaged or overwritten, etc.... then there goes your info. so it is my advice to definitely keep both of these files, the CUE being the more vital of the two, but the LOG file does contain some valueable information, such as what drive was used, what read offset was applied, what mode and options were used for extraction (ie, burst mode, secure...... C2 on/off, defeat cache on/off, whether it was test and copy or just copy...... etc). while embedded CUE's are a great invention/thought in my opinion, they are merely an accessory to the original files.. it all depends on your needs and plans for the end-result files, and how important this data is for you to know.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-02 21:33:09
Code: [Select]
[Disc ID: 000dd63b-006583a0-83099c09]
Offset applied: -12
Track [ CRC    ] Status
 01 [ba95e59a] (02/273) Accurately ripped
 02 [a8de475e] (02/272) Accurately ripped
 03 [03219797] (02/270) Accurately ripped
 04 [3de7bdf7] (02/270) Accurately ripped
 05 [850d915c] (02/272) Accurately ripped
 06 [69b9e193] (02/272) Accurately ripped
 07 [f9a80d41] (02/272) Accurately ripped
 08 [5898d55b] (02/273) Accurately ripped
 09 [ef69e35b] (02/272) Accurately ripped
Offsetted by 329:
 01 [217d2cb7] (05/273) Accurately ripped
 02 [035c1d8c] (05/272) Accurately ripped
 03 [a533954d] (05/270) Accurately ripped
 04 [d1f7212f] (05/270) Accurately ripped
 05 [9a2463af] (05/272) Accurately ripped
 06 [904d925e] (05/272) Accurately ripped
 07 [17cae0f8] (05/272) Accurately ripped
 08 [34343d89] (05/273) Accurately ripped
 09 [c8271051] (05/272) Accurately ripped
Offsetted by 341:
 01 [1cd853e0] (04/273) Accurately ripped
 02 [91da70b4] (04/272) Accurately ripped
 03 [9d7d875a] (04/270) Accurately ripped
 04 [e1d83940] (04/270) Accurately ripped
 05 [6748aa4c] (04/272) Accurately ripped
 06 [a9d12131] (04/272) Accurately ripped
 07 [d0e63c0e] (04/272) Accurately ripped
 08 [6c22ff5c] (04/273) Accurately ripped
 09 [67203a95] (04/272) Accurately ripped
Offsetted by 676:
 01 [922d88d6] (96/273) Accurately ripped
 02 [b6776a6b] (97/272) Accurately ripped
 03 [1fedfbf8] (96/270) Accurately ripped
 04 [eee24ed4] (95/270) Accurately ripped
 05 [c3e2e7d8] (96/272) Accurately ripped
 06 [9765fb3c] (96/272) Accurately ripped
 07 [cddeaa76] (97/272) Accurately ripped
 08 [629629fb] (98/273) Accurately ripped
 09 [453a7cea] (97/272) Accurately ripped
Offsetted by 679:
 01 [9f975e6e] (02/273) Accurately ripped
 02 [5a2867c4] (02/272) Accurately ripped
 03 [b7721e2d] (02/270) Accurately ripped
 04 [bd11a24e] (02/270) Accurately ripped
 05 [b472399f] (02/272) Accurately ripped
 06 [bfc91568] (02/272) Accurately ripped
 07 [70fe8f61] (02/272) Accurately ripped
 08 [ec601096] (02/273) Accurately ripped
 09 [ee968783] (02/272) Accurately ripped
Offsetted by 688:
 01 [4243df36] (139/273) Accurately ripped
 02 [5dea426d] (137/272) Accurately ripped
 03 [9f134244] (136/270) Accurately ripped
 04 [6ad09f50] (137/270) Accurately ripped
 05 [b95b2ee4] (138/272) Accurately ripped
 06 [42aa5b5d] (138/272) Accurately ripped
 07 [106f485b] (137/272) Accurately ripped
 08 [8ad24295] (137/273) Accurately ripped
 09 [eac5a754] (137/272) Accurately ripped
Offsetted by 1334:
 01 [e610378c] (25/273) Accurately ripped
 02 [f3d1de68] (25/272) Accurately ripped
 03 [93f18218] (25/270) Accurately ripped
 04 [58080aa6] (25/270) Accurately ripped
 05 [c475ac1c] (25/272) Accurately ripped
 06 [1f85bfab] (25/272) Accurately ripped
 07 [496ebe59] (25/272) Accurately ripped
 08 [0cdc2a7a] (25/273) Accurately ripped
 09 [5031f924] (25/272) Accurately ripped
Offsetted by 694:
 01 [32a6a20e] (00/273) No matches
 02 [024e5e9d] (00/272) No matches
 03 [a6729aa7] (02/270) Partial match
 04 [21764818] (00/270) No matches
 05 [095b9925] (00/272) No matches
 06 [20cb77ec] (00/272) No matches
 07 [62d12e31] (00/272) No matches
 08 [9e0d8cba] (00/273) No matches
 09 [3d9dbc92] (00/272) No matches

Track [ CRC32  ] [W/O NULL]
 -- [AF100B4F] [2456AB51]
 01 [4228669B] [7BF7F2E1]
 02 [238807CB] [CD4C285F]
 03 [8315A79F] [BC9DBD64]
 04 [64962211] [4BE360F0]
 05 [7EE2427E] [70DD89C0]
 06 [5B5A9439] [D28DEA76]
 07 [0F5658D0] [96EB0926]
 08 [492D73CF] [D2173540]
 09 [A10D8475] [EF74D31B]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-11-02 22:26:14
OK, i can explain this to you... sorry if i you already understand this.

These groups of entries means that your rip had 02 matches of this CD, after applying the closest matching offset (-12), to bring the offset to 0, which is what you want, otherwise without that applied, your CD would have zero matches.  The following entries are other rips, with differing offsets to yours, but the "audio data" still is exactly the same as that rip (after applying that offset to your rip). So ultimately, it is saying that your CD had 02 matches out of 272 or 273 total. So each group is a match, with "offset xxxx" relative to your copy.

That is, the next closest rip to yours would be the next one, "Offsetted by 329", which means the data for that submission matches your CD exactly, although we'd have to apply +329 samples(?)  for them to match. once we apply that "offset", they match perfectly.

Same with the rest.

Seeing as though this was an encode, you probably have the options set to choose the closest offset to yours, then shift your rip by that amount of samples, then re-encode, so that it has some matches, rather than none. The reason for this is you would not want to apply the 1334 offset vs. -12 offset, because that is more data lost or samples difference from yours. In your output, it appears that the pressing with the offset of 688 is the  most "popular" or "frequent" result, since it has the most matches.. but that is not necessarily meaning that it is the "right" one, as there can be multiple "right" ones.

Hope that is clear to you, I tried to make it as understandable as possible! if you have questions or would like me or the others to expand on any of that, just let us know!

[edit] to directly answer your original question, referencing this:

<ACCURATERIPCOUNT> : 2
<ACCURATERIPCOUNTALLOFFSETS> : «multiple values» 273; 272; 270
<ACCURATERIPCOUNTWITHOFFSET> : «multiple values» 139; 137; 136; 138
<ACCURATERIPOFFSET> : +688
<ACCURATERIPTOTAL> : «multiple values» 273; 272; 270

This shows your rip is 'accurate' or matching to 2 other people's rips. the next line shows the total amount of entries for this CD in the AR database including all the different offsets, the third looks like the highest count of matches for any single rip, the fourth is the "most frequent" or rip with the most submitted matches, and again, the last is probably the total number of entries, including zero offset entries and offsetted entries.

The "true" answer is that your copy did not match ANY of the entries in the AR database, it was only after offset of -12 was applied to it that it now matches 02/273 of the disc entries in the DB.

The "ultimate" match or result would be your CD matches the most popular pressing, at zero offset (meaning it did not have to be changed at all to match these, it did right off the bat). So essentially, we could assume two things -- 1 your rip is "wrong" since your drive needs an offset applied to it for ripping and wasn't, so it is inaccurate. The second possibility is that you just have a completely unique pressing that nobody else has submitted.

Do you have any offset put into the options in EAC? If not, then that is probably the problem. (or if it was downloaded, they likely didn't enter the correct offset for their drive).. aka they didn't really know how to rip CD's properly.. this is why you can never really trust downloads to be "true". they could have been ripped with a terribly wrong offset, then applied to furthest matching offset (say, 1300). In this case, you would be missing data from the original audio, and never know it... it would check out correctly if you used CUETools/AR to check it after the offset had been applied.

As some may technically correct, even such a large offset applied is very unlikely to actually destroy any real "audio", the point is... it's not an identical/truly accurate rip of the CD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-03 16:59:54
Thank you very much for clearing that up so detailed. I do understand that now.
Now I wonder what that offset data usually is. Is that actually some kind of padding?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 17:08:47
The "ultimate" match or result would be your CD matches the most popular pressing, at zero offset (meaning it did not have to be changed at all to match these, it did right off the bat).
Thankfully you're using quotes since this is nonsense and I fear that making these kinds of statements is misleading.

(or if it was downloaded, they likely didn't enter the correct offset for their drive)
This is easily fixed by supporting those creating and delivering the music rather than stealing from them.

As some may technically correct, even such a large offset applied is very unlikely to actually destroy any real "audio", the point is... it's not an identical/truly accurate rip of the CD.
You are aware that the offset reference that was adopted has been legitimately called into question(?), so by your rationale, rips approved by AR aren't identical/truly accurate rips of the CD either.

My 2 cents (which was likely posted long ago in this thread):
All you need is for your rip to be verified by a complete set of tracks with the same offset to be pretty much guaranteed that there was nothing wrong with it.  Sure you can correct your offset so that it matches a particular pressing and perhaps it might correct your drive's offset to match the reference in the event that the correction wasn't configured in the first place.  Doing so will possibly throw out even more data, though what might be thrown out is likely nothing more than a very low-level signal found at the edge of the disc.  There may also be situations where tracks aren't cut properly and they either start or end abruptly with the rest of the data being assigned to the edge of an adjacent track.  An offset (sometimes thousands of samples) might actually fix the problem but cause the disc not to match a pressing in the database any longer.  In this situation, which offset would you prefer?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-11-03 17:22:03
sure, the information is usually silence/null samples... which basically means... 'nothing' is usually there. nothing of value, anyway.

i believe i read somewhere that there is usually a set amount of samples that most CD makers usually have as padding at the start and beginning of a CD, though i don't think they're required to. ultimately though, if you think about what it really is... samples... these are fractions of a second. so you would have to have a HUGE offset screwup to actually be cutting off audio. i believe (i could be wrong or off a bit, feel fee to correct me) that the frequency of an audio clip is how many samples per second. so if it is 44.1khz, which i believe computes to 44,100 samples in 1 second of audio. for DVD's or 48khz it is even more and some go to 96khz and beyond.

so if you look at the big picture, you'd have to have an offset of +/- 44100 to miss one second of audio. (again, this is how i understand it to be, i'm certainly no audio engineer). soooo... ultimately, i think that correcting such a small offset should ultimately have pretty much no effect on the track. (only at a very small digital level). this would be for ripping a single WAV file... as for ripping into multiple WAV files with gapless transitions, i'm honestly not sure how that works or doesn't work. maybe someone can enlighten us on that. i would assume if the offset was off by -628 (from where it should be) then you'd be 'adding' fake samples at the start of track 1, and subtracting 628 samples from the end of the track, making the next track start prematurely / before it was intended to. as mentioned though... with the human ear... fractions of a second... milliseconds.. the ear is not even going to notice any difference, audibly.

that is the best i can explain it with what i know... if anyone can clear up the offset thing when ripping multiple tracks on a gapless cd or whatever... that confuses me even.. sorry!

[edit]
greynol: i pretty much agree with what you said, as i understand it.. (some wording was confusing to me). of course the #1 way to do this is go out, buy the CD, find the correct offset for the drive you will rip your CD with, enter that offset into your ripping program, and have away. i am not promoting piracy, i am simply acknowledging reality and the fact that people do download CD's and was citing an example of why/how things could get obfuscated.

i have ripped my entire music collection of hundreds of CD's, and out of those.... most have perfect AR matches... say 95% have at least 2-3 matches on the same offset. Then again, there are a few dics that I own, physically have put the disc in and ripped it with the same settings, and i have gotten NO matches on my offset... but matches on other ones. then you get into the whole idea of pressings and this or that.. and how do we know the original submissions were accurate to begin with, that whole point is -- as the match numbers go up, so does your ability to say this is indeed a correct rip.... a rip that matches .... 32 other people's rips.

if you download something, you never know if they have adjusted the offset... by how much... what methods of extraction they used, etc. which is exactly why i was saying that downloading something was unreliable (not to mention illegal).

but anyway.. you can read more about what i meant in the above post... to clarify some of what i said.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-03 17:22:25
Doing so will possibly throw out more data, though what might be thrown out is likely nothing more than a very low-level signal found at the edge of the disc.


But actually there is no chance of losing something of the true audio track data when messing with offsets?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 17:28:20
But actually there is no chance of losing something of the true audio track data when messing with offsets?

What you just quoted from me just said there was a chance of losing something when messing with offsets.  Even if it is just low-level noise, it is still audio data that existed on the CD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-03 17:31:16
I have another question. Apparently AR does not count any higher than 200 for a certain pressing / offsetted version.
Is that normal?

Code: [Select]
Track	[ CRC    ] Status
 01 [ff1a33cd] (200/1189) Accurately ripped
 02 [a96740a2] (200/1202) Accurately ripped
 03 [de29bb78] (200/1205) Accurately ripped
 04 [db7903f4] (200/1192) Accurately ripped
 05 [021e266a] (200/1197) Accurately ripped
 06 [39389339] (200/1202) Accurately ripped
 07 [4937bb12] (200/1209) Accurately ripped
 08 [61e58ede] (200/1190) Accurately ripped
 09 [227c62b6] (200/1188) Accurately ripped
 10 [ad30491c] (200/1194) Accurately ripped
 11 [ae4764f5] (200/1185) Accurately ripped
 12 [9a53b280] (200/1178) Accurately ripped
Offsetted by -2594:
 01 [783bf666] (15/1189) Accurately ripped
 02 [f5ea371d] (15/1202) Accurately ripped
 03 [30c86498] (15/1205) Accurately ripped
 04 [130b52bc] (15/1192) Accurately ripped
 05 [e81c5a10] (15/1197) Accurately ripped
 06 [eba5b54a] (14/1202) Accurately ripped
 07 [d0ec685a] (15/1209) Accurately ripped
 08 [88e12a9a] (15/1190) Accurately ripped
 09 [5ae46ce9] (15/1188) Accurately ripped
 10 [30ef2018] (15/1194) Accurately ripped
 11 [17d63435] (15/1185) Accurately ripped
 12 [f81b9f66] (15/1178) Accurately ripped
Offsetted by -2147:
 01 [de72532f] (05/1189) Accurately ripped
 02 [fff75ae6] (04/1202) Accurately ripped
 03 [6302811d] (04/1205) Accurately ripped
 04 [858169ec] (03/1192) Accurately ripped
 05 [04f6789e] (04/1197) Accurately ripped
 06 [3140cbbc] (04/1202) Accurately ripped
 07 [7f3b3fa6] (04/1209) Accurately ripped
 08 [2566075f] (04/1190) Accurately ripped
 09 [0699f2d8] (04/1188) Accurately ripped
 10 [3a0573d0] (03/1194) Accurately ripped
 11 [6ef2c9d5] (04/1185) Accurately ripped
 12 [a92e5d69] (03/1178) Accurately ripped
Offsetted by -1930:
 01 [d6e9da2c] (111/1189) Accurately ripped
 02 [21321107] (112/1202) Accurately ripped
 03 [18fede85] (110/1205) Accurately ripped
 04 [89dda9d7] (106/1192) Accurately ripped
 05 [bc6101a0] (108/1197) Accurately ripped
 06 [77c17916] (111/1202) Accurately ripped
 07 [0c2cd540] (112/1209) Accurately ripped
 08 [ae55bc2d] (107/1190) Accurately ripped
 09 [3b74a5f0] (106/1188) Accurately ripped
 10 [2ec8645c] (109/1194) Accurately ripped
 11 [9c19dd35] (108/1185) Accurately ripped
 12 [0c50a99e] (105/1178) Accurately ripped
Offsetted by -1466:
 01 [a69a5291] (153/1189) Accurately ripped
 02 [3f6d59ba] (158/1202) Accurately ripped
 03 [2969b033] (163/1205) Accurately ripped
 04 [c2f02f6a] (163/1192) Accurately ripped
 05 [b59baeff] (162/1197) Accurately ripped
 06 [d77b92cb] (162/1202) Accurately ripped
 07 [a2c2fbfe] (163/1209) Accurately ripped
 08 [8f940e06] (160/1190) Accurately ripped
 09 [e7c82b9c] (154/1188) Accurately ripped
 10 [765b3ccc] (161/1194) Accurately ripped
 11 [8c932b35] (153/1185) Accurately ripped
 12 [dcbfc02e] (156/1178) Accurately ripped
Offsetted by -1060:
 01 [f21d9326] (11/1189) Accurately ripped
 02 [f90d74b9] (12/1202) Accurately ripped
 03 [efcbf98a] (13/1205) Accurately ripped
 04 [28eb1130] (13/1192) Accurately ripped
 05 [4ec1f548] (13/1197) Accurately ripped
 06 [0cc94d81] (13/1202) Accurately ripped
 07 [b426db23] (12/1209) Accurately ripped
 08 [45a42fa6] (12/1190) Accurately ripped
 09 [e01483f9] (13/1188) Accurately ripped
 10 [1080e060] (13/1194) Accurately ripped
 11 [9efd4f75] (13/1185) Accurately ripped
 12 [3320f3ec] (13/1178) Accurately ripped
Offsetted by -994:
 01 [072ed398] (200/1189) Accurately ripped
 02 [fe12781b] (200/1202) Accurately ripped
 03 [6ddb1e82] (200/1205) Accurately ripped
 04 [d0301746] (200/1192) Accurately ripped
 05 [0852cfe4] (200/1197) Accurately ripped
 06 [86374e04] (200/1202) Accurately ripped
 07 [18d59a8e] (200/1209) Accurately ripped
 08 [7c13429b] (200/1190) Accurately ripped
 09 [fc3ce3de] (200/1188) Accurately ripped
 10 [cadc3efc] (200/1194) Accurately ripped
 11 [b6290c35] (200/1185) Accurately ripped
 12 [164b3ca6] (200/1178) Accurately ripped
Offsetted by -933:
 01 [97eca216] (08/1189) Accurately ripped
 02 [0c41ed63] (08/1202) Accurately ripped
 03 [f0afc05c] (07/1205) Accurately ripped
 04 [df73781d] (07/1192) Accurately ripped
 05 [945eeed4] (07/1197) Accurately ripped
 06 [bcce0c24] (08/1202) Accurately ripped
 07 [81a9b79b] (08/1209) Accurately ripped
 08 [ea2c1d73] (08/1190) Accurately ripped
 09 [53a39694] (08/1188) Accurately ripped
 10 [40d43a17] (08/1194) Accurately ripped
 11 [09a2ed15] (08/1185) Accurately ripped
 12 [77c3c5af] (08/1178) Accurately ripped
Offsetted by -669:
 01 [25ebab40] (06/1189) Accurately ripped
 02 [56dc7eb9] (06/1202) Accurately ripped
 03 [d28e6488] (06/1205) Accurately ripped
 04 [3ced2f03] (06/1192) Accurately ripped
 05 [c5a9312a] (06/1197) Accurately ripped
 06 [ae37afe3] (06/1202) Accurately ripped
 07 [c551eb3e] (06/1209) Accurately ripped
 08 [fcaa8526] (06/1190) Accurately ripped
 09 [358cb9b9] (06/1188) Accurately ripped
 10 [d0b828e5] (06/1194) Accurately ripped
 11 [6651e015] (06/1185) Accurately ripped
 12 [046ce897] (05/1178) Accurately ripped
Offsetted by -293:
 01 [23ef3bed] (23/1189) Accurately ripped
 02 [3bdc59ac] (23/1202) Accurately ripped
 03 [dff7af08] (23/1205) Accurately ripped
 04 [d759fcc4] (23/1192) Accurately ripped
 05 [1acdb741] (23/1197) Accurately ripped
 06 [28850cef] (23/1202) Accurately ripped
 07 [f686f549] (23/1209) Accurately ripped
 08 [71fb3196] (23/1190) Accurately ripped
 09 [0f534a80] (23/1188) Accurately ripped
 10 [2252eb2f] (23/1194) Accurately ripped
 11 [e290dd15] (23/1185) Accurately ripped
 12 [50a39e2f] (23/1178) Accurately ripped
Offsetted by -287:
 01 [e4c5601b] (02/1189) Accurately ripped
 02 [bf9aaa5a] (02/1202) Accurately ripped
 03 [c2395d28] (02/1205) Accurately ripped
 04 [102c7e50] (02/1192) Accurately ripped
 05 [3fbc2af3] (02/1197) Accurately ripped
 06 [be957160] (02/1202) Accurately ripped
 07 [3fc67275] (02/1209) Accurately ripped
 08 [8a99b981] (02/1190) Accurately ripped
 09 [8b50c28b] (02/1188) Accurately ripped
 10 [d3fc91f8] (02/1194) Accurately ripped
 11 [cd664b55] (02/1185) Accurately ripped
 12 [1f78ea9d] (02/1178) Accurately ripped
Offsetted by -275:
 01 [7aa357f0] (02/1189) Accurately ripped
 02 [a1d728bd] (02/1202) Accurately ripped
 03 [86bcb968] (02/1205) Accurately ripped
 04 [51a8ba2b] (02/1192) Accurately ripped
 05 [333f9584] (02/1197) Accurately ripped
 06 [e8d89647] (02/1202) Accurately ripped
 07 [c39c82f5] (02/1209) Accurately ripped
 08 [07dfd570] (02/1190) Accurately ripped
 09 [2f9e38f5] (02/1188) Accurately ripped
 10 [37d8deb0] (02/1194) Accurately ripped
 11 [a31127d5] (02/1185) Accurately ripped
 12 [bd238379] (02/1178) Accurately ripped
Offsetted by -269:
 01 [57e5b427] (200/1189) Accurately ripped
 02 [fcb454ba] (200/1202) Accurately ripped
 03 [68fe6788] (200/1205) Accurately ripped
 04 [d6e44acb] (200/1192) Accurately ripped
 05 [3f80d202] (200/1197) Accurately ripped
 06 [4fd075a6] (200/1202) Accurately ripped
 07 [8e62db7e] (200/1209) Accurately ripped
 08 [651e9574] (200/1190) Accurately ripped
 09 [2bcc0f21] (200/1188) Accurately ripped
 10 [ea34849c] (200/1194) Accurately ripped
 11 [8de69615] (200/1185) Accurately ripped
 12 [8bf8cfe7] (200/1178) Accurately ripped
Offsetted by -36:
 01 [b164b641] (09/1189) Accurately ripped
 02 [cabc1f16] (09/1202) Accurately ripped
 03 [909fa6b8] (09/1205) Accurately ripped
 04 [074c16c5] (09/1192) Accurately ripped
 05 [35554345] (09/1197) Accurately ripped
 06 [930599b2] (08/1202) Accurately ripped
 07 [9163b790] (09/1209) Accurately ripped
 08 [cd982676] (09/1190) Accurately ripped
 09 [6e469845] (09/1188) Accurately ripped
 10 [9ae27fe6] (09/1194) Accurately ripped
 11 [2d46cf75] (09/1185) Accurately ripped
 12 [c153e7ec] (09/1178) Accurately ripped
Offsetted by 260:
 01 [9feea860] (16/1189) Accurately ripped
 02 [bc51fc97] (15/1202) Accurately ripped
 03 [7ff28a38] (15/1205) Accurately ripped
 04 [468cf5f5] (15/1192) Accurately ripped
 05 [a050997d] (15/1197) Accurately ripped
 06 [62064d29] (16/1202) Accurately ripped
 07 [5ac401a5] (16/1209) Accurately ripped
 08 [d76369d8] (14/1190) Accurately ripped
 09 [fef74b5e] (15/1188) Accurately ripped
 10 [99d335b7] (16/1194) Accurately ripped
 11 [6e680e75] (15/1185) Accurately ripped
 12 [f26ea274] (14/1178) Accurately ripped
Offsetted by -1062:
 01 [9acb0d77] (00/1189) No matches
 02 [a4d77b64] (02/1202) Partial match
 03 [4fc98f44] (02/1205) Accurately ripped
 04 [9c51174e] (02/1192) Partial match
 05 [b08bc1de] (02/1197) Partial match
 06 [015b10a6] (02/1202) Partial match
 07 [6306028c] (02/1209) Accurately ripped
 08 [cb1fa93c] (02/1190) Partial match
 09 [4e8b90eb] (02/1188) Partial match
 10 [311c632e] (02/1194) Partial match
 11 [50b62ab5] (02/1185) Accurately ripped
 12 [98d9da72] (00/1178) No matches
Offsetted by -263:
 01 [a93820d1] (00/1189) No matches
 02 [47c272fc] (00/1202) No matches
 03 [4b4015a8] (02/1205) Partial match
 04 [4e0ebcb9] (00/1192) No matches
 05 [401c0e52] (00/1197) No matches
 06 [45b432c3] (00/1202) No matches
 07 [337a36e6] (00/1209) No matches
 08 [055ab6f5] (00/1190) No matches
 09 [286504c8] (00/1188) No matches
 10 [9cef2a6b] (00/1194) No matches
 11 [78bc0455] (00/1185) No matches
 12 [5ace1c55] (00/1178) No matches

Track [ CRC32  ] [W/O NULL]
 -- [3BBB0CA0] [355759D8]
 01 [0F7402B6] [F6947445]
 02 [081D405C] [B5CCBB6E]
 03 [69B3F7C7] [7607E5EC]
 04 [8E90AE6B] [18E99A29]
 05 [D84DB09D] [E9414728]
 06 [096618CA] [D89ECD71]
 07 [8344C953] [D9032AAF]
 08 [C77AC9BD] [09EB9510]
 09 [4E46DDD6] [4A9FBB20]
 10 [0E3F6A5B] [DB270654]
 11 [1E10CC16] [12401A96]
 12 [4679A4F7] [F31A7A4E]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 17:33:55
sure, the information is usually silence/null samples.

Have you actually conducted a study or are you just guessing?

as the match numbers go up, so does your ability to say this is indeed a correct rip

Except for rare circumstances dealing with firmware bugs or manufacturing defects that exploit problems with specific chipsets and/or ripping programs, a high confidence guarantees you nothing over a low confidence.  It's my belief that the ability to verify against more than one pressing is more meaningful than the level of confidence of any of those pressings.  This includes the potential for situations involving manufacturing defects and bugs with software or firmware.

i would assume if the offset was off by -628 (from where it should be) then you'd be 'adding' fake samples at the start of track 1, and subtracting 628 samples from the end of the track, making the next track start prematurely / before it was intended to. as mentioned though... with the human ear... fractions of a second... milliseconds.. the ear is not even going to notice any difference, audibly.

Actually it can very easily be audible depending on where the cut takes place.  Perhaps it would help for you to contemplate the question I posed at the end of my post. (EDIT: and no, the track doesn't have to be cut by thousands of samples for it to be audible.)

Another question would be that if applying an offset to the data is not audible, then why bother in the first place?  So that the rip will match an entry in the AR database?  Is the exercise of using a program to verify them against alternate pressings not enough?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 17:35:30
I have another question. Apparently AR does not count any higher than 200 for a certain pressing / offsetted version.
Is that normal?

Yes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-03 18:27:39
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
So how come all these different offsetted versions are in the database anyways?
Must they all not just be from different pressings?
Basically a true accurate rip would be ripped at zero offset?
How am I supposed to tell which offsetted version is the true accurate one when all shown versions have just relative offsets to other rips? As far as I understand now that can only be guessed by the most popular rip.

When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-11-03 18:34:35
sorry, i don't have the time to fully read through and respond yet, but i was going to cite this info i just pulled up:

A CD audio disc is divided into sectors. Each sector holds 1/75 seconds of        audio, or 588 samples at 44100 samples per second, or 2352 bytes. If the size        of a WAV recording is not a multiple of 588 samples, the recording software        will fill the remainder of the sector with zeroes. If you have a continuous        recording (live), you'll hear a short click in between two songs, as a result        of the padding zeroes. To prevent this, the program always cuts on 588 sample        borders, so two adjacent songs will have no clicks in between.

so that may be an example of how an offset could screw with things. this would really only apply to a live/gapless CD that is extracted to multiple files, and then a method of gap handling is chosen. this is one reason why i choose to rip my CDs in SINGLE WAV mode... therefore it is 1 WAV file, not WAV files that are going to be rejoined based on sectors and cue times.even if the offset were off a bit, there wouldn't be any of this zero filling causing pops or clicks... since there is no partitioning of the original data (other than at a super low level).

since 99% of the time there is silence or null/0 samples before the first track and after the last one, i believe in this case (single wav + cue) could be identical to a rip using a different offset. for example... if the first 100 samples of a CD are nothing but zero padding/null or even "silence", if you are off by 6 samples, either way it can be the same result, since EAC can be made to "fill missing samples with silence"... if on the disk in those same 6 samples, it was actually silence anyway, then you in effect have used an incorrect offset but achieved an identical result as if you had used the right one.


all in all, it's a pretty moot point... as i mentioned... i advise to rip only to single wav/image rather than file-per-track. you are right off the bat eliminating extra WAV headers, etc... possibly modified or filled data (depending on how the program handles a junction or split)... you could go pretty low level with it, but the simple point is... in response to one of your questions -- what is the purpose of offset correction? just to make it match a set of results? -- actually yes, IMO, this is what most people use it for... so it matches up with something so they can say ok it matches, it's accurate. if it matches, it matches. CRC's are going to differ if the data is not identical. (yes, again for the super super techie, it's POSSIBLE that two different files could calculate to the same CRC value... but let's be realistic). the more proper usage of offset correction would be if i ripped 20 cd's on my drive... then realized i didn't put in the correct offset... on mine it's +6. rather than re-rip 20 cd's, since i KNOW what offset they SHOULD have been ripped using, I can use this validated knowledge to make this correction... it wouldn't be a guess.. it would be what the discs should have been read as anyway.

even so, in either instance, you could possibly end up with identical match still, or a different one. there is the possibility (but it is unlikely) that you will be replacing your missing samples with the wrong thing.

in the end, offset correction = losing data somewhere. either at the front or the tail end, depending if the offset is +/-. when you're correcting, you're ASSUMING that the missing samples were a certain value (silence/null values)... most of the time, the guess is correct, and you end up with matching CRC's because of the simple fact that CD's generally never start the audio right at sample 0 or end the audio at the very last sample. there is a bit of lag in when the actual AUDIO begins on the physical layout, and where the physical layout itself begins. here's your test... take a cd... rip a wav.. put in an offset you know is wrong. you know your correct one... then take a look at those x samples that were originally not there or were spilled over into. that can give you your answer.. if you need to get a dang hex editor out and look at it byte per byte.

i guess i've kind of made my side of the argument, i believe we are thinking the same thing, but our expression of those ideas in writing sound different.. who knows... i can't say i'm 100% right, and neither can you or the next guy just by opinion and objective knowledge. either way, it's not a point worth getting frenzied over... buy the CD's.. make sure you have the correct offset for your drive in there, then you're pretty much good to go.

this is why with the exception of a few strays, my rips always match up with at least one, usually multiple sets/pressings.. often all offsets match. can i feel confident when i rip my own cd with the correct settings then get results from AR/CueTools saying that my rip is 167/167, all offsets matching? yes, absolutely.

AR is not to 100% absolutely prove without a shadow of a doubt your audio rip is a bit for bit copy of that CD.... it's yet another layer of authentication/validation that it is right. i mean..... if you do a test&copy and get the same CRC result both times, you get results that match .... xx amount of other people who have copied the same cd....... you can sleep well enough at night.... you can pretty much say that with 99.9% accuracy your rip is perfect as anyone else's. i'm cool with that. i try to "never say never" cause there are always exceptions and those super rare 1 in a million things that can happen to prove to us that .... NEVER?? ... psh..  never loves to prove people wrong 

oh... btw.... i will honestly admit that i'm not 100% positive on the difference between null samples, zero'd samples and "silence". i assume that null = 0's as bit data, so null and zero would seem to be the same to me..(though technically something that is "null" doesn't exist, but i'm pretty sure it means 0's). as for silence... what is silence? if it is well below your physical threshold/capacity to hear, is it silence? it's silent to you, since you do not have the capacity to perceive it.... but there's still noise there....................... or is there?........... maybe it's all a dream........ *brain spasm* just wanted to get all philosophical on ya arses to make things a little lighter. everything is relative, my friends.. a person who is 'color blind' may look at blue and say it's orange..... you laugh and go... you idiot. it's blue.  what is blue? a wavelength of light..... what makes that wavelength of light "blue"??? --- our perception.. and perception is relative -- therefore can reality be relative and not absolute?  to each individual, their perception is "reality". who is right? nobody can ever know for sure........

man. 10 minutes ago we were talking about ripping CD's.... now i'm questioning my own existence... haha
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 18:53:10
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
Sure, though it's possible to submit results from CD-R an I think it's possible for results to come from an incorrectly configured drive that is not in the database and that these results can be available if it either has matches or there are no other entries with matches for the same disc ID.

So how come all these different offsetted versions are in the database anyways?
Different manufacturing runs often produce versions with different offsets, assuming, of course the TOC stays the same.

Must they all not just be from different pressings?
Your use of the word "not" is making this difficult for me to understand, but I think I've explained it.

Basically a true accurate rip would be ripped at zero offset?
No.  Notwithstanding the debate over what is the correct reference, there is little if any reason for one to conclude that one pressing is more true than another.

As far as I understand now that can only be guessed by the most popular rip.
I tried to dispel this notion.  Oh well.

When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?
AR can keep multiple checksums (which are not CRCs, BTW) for each track per disc ID.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 19:15:20
so that may be an example of how an offset could screw with things.
Actually, no.  Offsets result in data shifting, they do not change the lengths of tracks unless you tell your ripping program not to pad missing samples with silence which will only affect either the first or last track on the disc.  Your confusion with this is not helping progress the discussion.
all in all, it's a pretty moot point... as i mentioned... i advise to rip only to single wav/image rather than file-per-track.
I would advise that people ignore your advice.  Sorry that this sounds harsh, but you appear to be getting in way over your head.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-11-03 19:25:50
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
So how come all these different offsetted versions are in the database anyways?
Must they all not just be from different pressings?
Basically a true accurate rip would be ripped at zero offset?
How am I supposed to tell which offsetted version is the true accurate one when all shown versions have just relative offsets to other rips? As far as I understand now that can only be guessed by the most popular rip.

When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?


between the post i just made, and this one you just made... i think you may have destroyed my brain..... seriously hahah.. you are very inquisitive... but there's nothing wrong with that... but you sure have given me a mind****!

let's get simple again... CD's are made in batches, or pressings. say a factory gets an order for 10,000 copies of a CD. they get the master plates, and they duplicate every CD of that master (simply put.. they can only make so many copies before they begin to wear out but that's outside the point)...... that's a batch.  the audio data on those pressings starts at a certain spot.

later on, they run out... we need another 10,000... they have another factory whip them up another batch. for whatever reason or another, the audio data can be slightly off/different, though it is the same CD technically.... i suppose becauses of different pressing equipment, this or that... there's always some margin for small error.

you're going to possibly get two different CRC results when ripping these two pressings with the same burner, etc.

then you have some pressings or sets that do not match... for instance, one version may have a hidden track after 3 minutes of silence on a re-release or special edition... in that case, you'll get matches possibly on all of the tracks except the last one.

there are many reasons why any two of the same "album" can truly have different offsets.... and they can both be right. there may really be 30 people out there with a copy of the disc that came from batch X where the offset, to THEM is ZERO... given an accurate rip. to you, with a different pressing, that had a slight difference in where the audio started because it was made at a different time or pressing plant -- will also have a ZERO offset if your settings are right.

-- and you both have accurate rips. there is no such thing as a single correct rip... you just see theirs as being "X" samples off from yours.... that's why they call them offsets...... cause the start of their data is OFFSET from yours by so many samples. offset essentially meaning "the difference" in reference points. just imagine it like this... two different pressings..... both physical... true blue factory copies....

disc one:


00000000000000101010001111001100101001110110100110101
                                    ^ start of the audio data

disc two:

00000000000000000000000000010101010010101010101001111
                                                                        ^ start of the audio data


in this example, if disc one is ripped and verified against disc two... disc two will show up as a match, with an offset of +13, because it has the same audio fingerprint... it's just shifted up 13 places from the first... or offset by +13 samples.

likewise, if the owner of disc two were to rip his copy and verify it against the database.... disc one would show up as an (offset) match as well... but his would show their rip is -13 offset... because it starts 13 positions before theirs does on the physical cd.

i hope that makes it more clear for you to understand... by the way that may not be perfect, i roughly counted 13 more 0's before disc two kicked in. don't take my crappy drawings as true technically.... it is just a visual example. sometimes things are easier  when they are visual.

in an ideal world, all drives and lasers would start at the same spot on the disc, every time. but they are not perfect, and that is why we have drive offsets as well. because of calibration or mechanical difference:

drive one may begin to read the disc physicaly at position 3.

0000000000000
    ^--- laser doesn't exactly start on the ACTUAL beginning of the disc data, it's positioned a little ahead.... ack. we need to tell it to back up... this drive needs to have an offset of -3 to tell it "hey... you're starting late... there's data that's supposed to be back there and you didn't even catch it... better put something there......... what was there? i dunno..... probably 000's.... that's what 99% of CD's start with... some zero's... so instead of writing the data as ???000000 i'll write it out as 000000000. (luckily, this matches what was truly missed during the read, so the track is actually identical still!)

as a counter example, drive two may actually read BEFORE the disc even starts, for example

------------00000000
  ^-- begins reading before the data even begins! in this case, the drive would have to have a positive offset applied to it, that is, a correction applied to it to tell it to not start reading any data until after, say, 7 positions. so when the drive begins to read this disc... it will ignore the first 7 bits it reads... THEN it will start copying the data. by giving it an offset, (or an offset correction, more specifically) we have eliminated it from reading garbage from the first 7 positions. for all we know there could have been an imperfection on one of those first 7, which the drive might have accidentially read as a 1... when there is truly nothing there... it was an error. without telling it the offset, it would have picked up that incorrect garbage bit, and thrown the whole thing off... and your starting point would be all jacked up and everything may just be plain wrong after that mishap.

went into a lot more detail that i planned there..... aaah! just trying to help you out, my friend.  these can be tough concepts to learn, and i'm still learning, myself. that's ok though, because in reality, this stuff can and does get quite technical... and can get confusing very quickly.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-11-03 19:28:29
I haven't read all the recent discussion so I am only answering SpaceAgeHero's post:

Quote
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
True
Quote
So how come all these different offsetted versions are in the database anyways?

These offsets are applied by the burner/writer of the music compagnie.
Quote
Must they all not just be from different pressings?

True, they are. (See previous answer)
Quote
Basically a true accurate rip would be ripped at zero offset?

Wrong, as long as you can detect it, the offset doesn't matter.
Quote
How am I supposed to tell which offsetted version is the true accurate one when all shown versions have just relative offsets to other rips? As far as I understand now that can only be guessed by the most popular rip.

There is no "true accurate version" your whole concept is flawed & due to a missunderstanding of offsets. The "most popular rip" is not more accurate, it is only ... the most popular.
Quote
When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?

The offset itself cannot be data, it's a word abuse. The offset is a positive or negative sample numbers. Think of it as a cutpoint, a cutpoint doesn't have a lenght. Think of it as if it didn't have a lenght: then the offset become nothing more than a positive or negative shift of the cutpoint between song.
(NOTE: This is a simplification for you to understand, the offset doesn't shift the cutpoint (the cutpoints are static within the cue sheet no matter the offset), it shift the whole audio data, but in a way the result is the same, it modify the splitpoint between songs)
As long as you cut right in the middle of silence between two song then the offset will not really matter as the CRC will still be the same & match.
As soon as you shift the data cutpoint so much that you fall in the middle of audio data (even not listenable noise data) then the CRC will not match.

So, as long as all tracks are AR2 within the same offset, different pressings with only a different offset are in fact the exact same data, that's why AR count all these rips as accurate no matter the offset.

If between 2 pressings with 2 different offsets all song are accurate except 1, it means the offset was small enough to not fall right in the middle of data, for all songs EXCEPT the one that is suddenly not accurate. In this case you shouldn't correct offset.

Personnaly I correct offset to most popular IF & only IF all tracks (100% in advanced settings) are AR2 (minimum) within the same offset for the 2 pressings (My rip & the Target (Most popular)). Don't correct offset has long has you don't understand them fully you can lose data if you do a misstake, specially with big negative offset.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-03 19:44:15
Okay guys. Thank you very much for your time and all this interesting information.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2009-11-03 19:45:23
so that may be an example of how an offset could screw with things.
Actually, no.  Offsets result in data shifting, they do not change the lengths of tracks unless you tell your ripping program not to pad missing samples with silence which will only affect either the first or last track on the disc.  Your confusion with this is not helping progress the discussion.
all in all, it's a pretty moot point... as i mentioned... i advise to rip only to single wav/image rather than file-per-track.
I would advise that people ignore your advice.  Sorry that this sounds harsh, but you appear to be getting in way over your head.


i'm afraid that you may be confused in saying that i'm feeding him lies and false information. i'm not getting in over my head, i understand that an offset is a relativity in position in the physical sector layout on a disc. as i clearly demonstrated in my last post there, both verbally and visually... the concept of what an offset is, how it is relative, WHY it is relative to each drive and disc pressing.....

please don't tell me that i don't understand the concept of an offset.i may not know the low-level technical details of the format, how it is encoded exactly, but i do understand the general ideas.


i was an assembly language programmer for 3 years... where i had to calculate and implement offsets to read/write values from memory every single day... i understand what offsetting means, and relative positioning, indexing of data fields... it's like telling an electrician that he doesn't understand what alternating/direct current, volts, amps, etc are.

so i'll end this here and i think you should as well, and we will let other people come into the discussion and give them a chance to participate and give their own understanding of what is right and what is not.

i don't think they'll call me an idiot who doesn't have a clue... like you basically have. we will agree to disagree... or at least i will. we have dissenting opinions.... good. that makes for good discussion... otherwise the boards would be boring if everyone was just like "yeah.. you're right. that's right what he said. topic closed." debate is good, argument is not... so i am stepping out of this one and letting things cool down and give some others a chance to respond to the probably now VERY confused SpaceAgeHero. they've got me trying to help out and clear up some of their questions, and i'm making an effort to help this person out, and you're just coming behind me saying no that's wrong. i'm afraid you're confused. nope, now you're feeding false information, you don't have a clue what you're talking about.....

instead of antagonizing, how about you put in the time and effort i have into explaining to this poor soul these concepts. i want to see you explain to SpaceAgeHero how it works if i'm wrong. show me that i'm wrong... don't just tell me. if you prove me wrong... by all means i will swallow my pride and say you know what... you got me. you were right. so i now offer the stage to you and the others to ANSWER their question, rather than criticize my responses.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 19:57:59
Sorry but throwing out extraneous information about sector boundaries doesn't give me much confidence that you understand what an offset is, or how it relates to this discussion.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-11-03 20:07:52
Completely off-topic but is it just me or Gregory S. Chudov left the boat since he started to code for fake & flacuda ? CUETools is much more interesting piece of software IMHO.

According to Spoon accuraterip database is supposed to be updated every 2 or 3 months so it is likely that it will be updated sometime during this month. Is there any chance that we would have a new cuetools version at the same time the database gets updated  ... or am I dreaming wide awake ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 20:10:10
Quote
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
True
No, I gave an example demonstrating that this assertion is false.

As long as you cut right in the middle of silence between two song then the offset will not really matter as the CRC will still be the same & match.
This is only true for a specific modification to the CRC calculation that can be implemented by EAC which basically strips any data with zero amplitude from either the left or right channel.  It is not the case for AR hashes or the standard CRC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 20:17:16
went into a lot more detail that i planned there..... aaah! just trying to help you out, my friend.  these can be tough concepts to learn, and i'm still learning, myself.

Ah, then I'd start by researching EFM and CIRC since your example of the laser positioning was pretty far off the mark, but to your credit you did a good job demonstrating what an offset is.  You might find this interesting as well:
http://club.myce.com/f52/offsets-handling-...channel-111913/ (http://club.myce.com/f52/offsets-handling-syncing-audio-data-vs-q-channel-111913/)

Why you brought up sector boundaries is still a mystery to me though.  In other words, this is complete nonsense:
so that may be an example of how an offset could screw with things. this would really only apply to a live/gapless CD that is extracted to multiple files, and then a method of gap handling is chosen. this is one reason why i choose to rip my CDs in SINGLE WAV mode... therefore it is 1 WAV file, not WAV files that are going to be rejoined based on sectors and cue times.even if the offset were off a bit, there wouldn't be any of this zero filling causing pops or clicks... since there is no partitioning of the original data (other than at a super low level).

you are right off the bat eliminating extra WAV headers, etc... possibly modified or filled data (depending on how the program handles a junction or split)
Could you please cite a program that doesn't join wave files correctly?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-11-03 20:31:08
I correct myself:
Quote
As long as you cut right in the middle of silence between two song then the offset will not really matter as the CRC will still be the same & match if you fix the offset.
Indeed if you don't fix the offset the CRC don't match as displayed within the accuraterip log.

It's hard to have the last word with Greynol  I thought he would kill me for suggesting to newbies to interpret the offset as a shift of splitpoints, that why I used the red for my note.

Edit: For the first point, your exemple is rather a temporary exception. As far as I understund how AR works, it is likely to be purged sooner or later when the drive become more popular or when a 2nd ripper rip the same CD & disagree. The normal behavior is that AR wants submission with the right offset correction.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-03 20:48:28
Naw, while I don't believe in correcting offsets simply so that they match the AR database and sometimes have a hard time with your English (I sometimes have a hard time even with my own English and it's my native language), I think your contributions to this topic have been quite good.  I've tried to keep an eye out for this thread, especially when it comes to people giving advice.  In the case of Chinch, much has been very good.  The advice that drew my sharpest criticism was the FUD over ripping to individual tracks.

Noting your edit, yes, I think you're right, though I don't know how long "temporary" might be.  I don't know how often the database is purged of questionable results.  I don't recall that it was very often.  Oh yeah, but if it's a sole entry without matches, it will be bumped once another entry hits the database.  IIRC, neither entry will then show until either of them gets a match from another submission with a unique user id.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-11-03 22:41:49
Completely off-topic but is it just me or Gregory S. Chudov left the boat since he started to code for fake & flacuda ? CUETools is much more interesting piece of software IMHO.

CUETools is interesting, but there's not much left to be done here. I'm always more excited by doing something new, besides i'm a bit busy at work currently.

There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc. Thanks for ideas and suggestions, i will at least consider them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-11-03 23:15:10
Hi Greg.

Actually the thing that I miss the most is a "fix offset only if the actual offset is not the most popular in database" mode, because actually it recodes everything blindly even if the result would end in the exact same encode.
More generally a "fix offset only if it actually really fixes something & skip when it doesn't" mode would made me save a lot of time not re-encoding twice a rip that is already with the most popular offset in the database. This would made me save time, money (energy) & wasted temporary HDD space.
This would just be as usefull IMHO as the actual "verify only if found" ... I am basically asking for a "fix offset only if fixable" mode. For someone who would use it, the benefit is comparable between the two modes.
I understand that people who don't fix offset will find this useless, but personnaly as I fix offset to make my accurip logs shorter, I find that this is really something missing.
I already asked for it & you told me to script it ... I wish I could ...

Also a "brute force attack" testing systematically all possible time length on data track would be usefull IMHO if it doesn't stress the database too much. Doing it manually is a pain & I have plenty of rips with old logs that don't include the data track length.
... and don't tell me to insert the CD in my drive ... when I could, I already did it

In the same way of thinking, a "brute force attack" on pre-gap with length 00:01 to say 00:59 would be interesting because I noticed that when you add a pre-gap of 00:32 or 00:33 (by far the most usual value) to some rips that are not present in database without pre-gap then if you're lucky you can fall on a set of matching CRC ... it happened to me several times (around ten times so far) so this is not unusual. It's just another kind pressing, just like there can be an offset difference, there can be a pre-gap difference & actually we do as if these pressings didn't exist.

Also a CD can have several value for the data track length ... don't ask me why it happened to me once when checking length manually & I think I recall it was a Pink Floyd CD ... the first set of CRC that I fall on had low confidency which was suspect for a Pink Floyd CD so I continued to check lenght & I finally falled on a very high confidency result. If I would have been lazy or non-suspect I would have stopped at after finding the first set of CRC. I guess it is far rarer than with artificially added pre-gap. But it happens ...

Then there is plenty of possible cosmetic fix/enhancements that would made the use of cuetools nicer ... if you want a TODO list I am sure I can create one as long as my arm
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-04 19:34:17
Hey guys,

it's me again with another question. I've been doing some tests with CUETools regarding dummy cue sheets.

I have ripped an album to 1 flac file per track + cue.
Now I converted it to wavpack using CUETools two times.

First I had the original cue file in the directory where the flac files are.
When I converted it everything was fine. Accurately ripped.

Code: [Select]
REM ACCURATERIPID 002d23b1-0288f713-0410be13
REM GENRE "Grunge"
REM DATE 2007
REM DISCID 0410BE13
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Foo Fighters"
TITLE "The Colour And The Shape"
FILE "The Colour And The Shape.wv" WAVE
  TRACK 01 AUDIO
    TITLE "Doll"
    PERFORMER "Foo Fighters"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Monkey Wrench"
    PERFORMER "Foo Fighters"
    INDEX 00 01:24:13
    INDEX 01 01:24:17
  TRACK 03 AUDIO
    TITLE "Hey, Johnny Park!"
    PERFORMER "Foo Fighters"
    INDEX 01 05:15:49
  TRACK 04 AUDIO
    TITLE "My Poor Brain"
    PERFORMER "Foo Fighters"
    INDEX 01 09:24:06
  TRACK 05 AUDIO
    TITLE "Wind Up"
    PERFORMER "Foo Fighters"
    INDEX 01 12:57:38
  TRACK 06 AUDIO
    TITLE "Up In Arms"
    PERFORMER "Foo Fighters"
    INDEX 00 15:28:36
    INDEX 01 15:29:31
  TRACK 07 AUDIO
    TITLE "My Hero"
    PERFORMER "Foo Fighters"
    INDEX 00 17:44:64
    INDEX 01 17:45:16
  TRACK 08 AUDIO
    TITLE "See You"
    PERFORMER "Foo Fighters"
    INDEX 01 22:05:01
  TRACK 09 AUDIO
    TITLE "Enough Space"
    PERFORMER "Foo Fighters"
    INDEX 01 24:31:61
  TRACK 10 AUDIO
    TITLE "February Stars"
    PERFORMER "Foo Fighters"
    INDEX 00 27:07:72
    INDEX 01 27:08:66
  TRACK 11 AUDIO
    TITLE "Everlong"
    PERFORMER "Foo Fighters"
    INDEX 01 31:58:12
  TRACK 12 AUDIO
    TITLE "Walking After You"
    PERFORMER "Foo Fighters"
    INDEX 01 36:08:24
  TRACK 13 AUDIO
    TITLE "New Way Home"
    PERFORMER "Foo Fighters"
    INDEX 00 41:12:27
    INDEX 01 41:12:37
  TRACK 14 AUDIO
    TITLE "Requiem"
    PERFORMER "Foo Fighters"
    INDEX 00 46:52:60
    INDEX 01 46:56:47
  TRACK 15 AUDIO
    TITLE "Drive Me Wild"
    PERFORMER "Foo Fighters"
    INDEX 01 50:30:06
  TRACK 16 AUDIO
    TITLE "Down In The Park"
    PERFORMER "Foo Fighters"
    INDEX 01 53:44:05
  TRACK 17 AUDIO
    TITLE "Baker Street"
    PERFORMER "Foo Fighters"
    INDEX 01 57:52:68
  TRACK 18 AUDIO
    TITLE "Dear Lover"
    PERFORMER "Foo Fighters"
    INDEX 01 63:30:21
  TRACK 19 AUDIO
    TITLE "The Colour And The Shape"
    PERFORMER "Foo Fighters"
    INDEX 01 68:02:35

See this here?

TRACK 02 AUDIO
    TITLE "Monkey Wrench"
    PERFORMER "Foo Fighters"
    INDEX 00 01:24:13
    INDEX 01 01:24:17

I wonder what this has to say.

So I did another test, but this time I removed the original cue file and had CUETools to generate a dummy cue file upon conversion.
Everything fine again. Accurately ripped with absolutely the same results.

This time I had this cue file:

Code: [Select]
REM ACCURATERIPID 002d23b1-0288f713-0410be13
REM COMMENT "CUETools generated dummy CUE sheet"
PERFORMER "Foo Fighters"
TITLE "The Colour And The Shape"
REM DATE 2007
REM GENRE "Grunge"
FILE "The Colour And The Shape.wv" WAVE
  TRACK 01 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Doll"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Monkey Wrench"
    INDEX 01 01:24:17
  TRACK 03 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Hey, Johnny Park!"
    INDEX 01 05:15:49
  TRACK 04 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "My Poor Brain"
    INDEX 01 09:24:06
  TRACK 05 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Wind Up"
    INDEX 01 12:57:38
  TRACK 06 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Up In Arms"
    INDEX 01 15:29:31
  TRACK 07 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "My Hero"
    INDEX 01 17:45:16
  TRACK 08 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "See You"
    INDEX 01 22:05:01
  TRACK 09 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Enough Space"
    INDEX 01 24:31:61
  TRACK 10 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "February Stars"
    INDEX 01 27:08:66
  TRACK 11 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Everlong"
    INDEX 01 31:58:12
  TRACK 12 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Walking After You"
    INDEX 01 36:08:24
  TRACK 13 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "New Way Home"
    INDEX 01 41:12:37
  TRACK 14 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Requiem"
    INDEX 01 46:56:47
  TRACK 15 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Drive Me Wild"
    INDEX 01 50:30:06
  TRACK 16 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Down In The Park"
    INDEX 01 53:44:05
  TRACK 17 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Baker Street"
    INDEX 01 57:52:68
  TRACK 18 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Dear Lover"
    INDEX 01 63:30:21
  TRACK 19 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "The Colour And The Shape"
    INDEX 01 68:02:35

  TRACK 02 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Monkey Wrench"
    INDEX 01 01:24:17

INDEX 00 01:24:13 is not there anymore. But still everything is recognized as accurate.

So I wonder what this is. Sorry for my noob questions. :/
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-04 19:43:12
INDEX 00 01:24:13 is not there anymore.
This information was lost when you removed the original CUE sheet.

But still everything is recognized as accurate.
AR doesn't use 00 indices.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-04 19:48:25
This information was lost when you removed the original CUE sheet.


Yes I know that. But what is that used for?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-04 19:50:43
http://wiki.hydrogenaudio.org/index.php?ti...AC_Gap_Settings (http://wiki.hydrogenaudio.org/index.php?title=EAC_Gap_Settings)

Please consult the wiki or search the forum instead of asking questions that are not relevant to this topic.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-11-04 19:50:47
My guess is that the gap was silence so appended or not, its null samples didn't affect the checksum.
Now as Greynol pointed out, I don't recall exactly when null samples are used or left out, but there is a rationnal explanation. I don't think the dummy cue sheet would have been accurate with gaps full of applauds or data, so your exemple is a special case that you cannot generalize.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2009-11-04 19:56:33


He's simply had CUETools generate a generic cue sheet for tracks with gaps appended to the previous track and then had CUETools convert these tracks + cue into a single-file image + cue.  There is really no need to muddy the waters with unnecessary discussion of null samples, checksums and whether the gaps contain non-null data.

It appears that this discussion has become quite bloated with unnecessary posts that aren't exactly on-topic.  I'd like to see a bit more sanity here.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-11-17 19:57:18
Hello,

apparently AccurateRip tags are not written into WavPack files on verification only.
Write tags on verification is ticked and after conversion everything is fine as well.
Am I doing something wrong?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2009-11-23 07:40:58
There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc.
Eagerly awaiting new build. Tried building it from sf but only managed the C# code.

Thanks for ideas and suggestions, i will at least consider them.
- Process unknown tags (or at least Composer and Comment) from CUE;
- Advanced Settings / Tagging / Copy unknown tags does not work for ALAC (could you at least add Composer and Comment);
- Write AccurateRip tags to ALAC;

cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2009-11-28 18:47:17
CUETools is interesting, but there's not much left to be done here. I'm always more excited by doing something new, besides i'm a bit busy at work currently.

There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc. Thanks for ideas and suggestions, i will at least consider them.

I use Cuetools 2.0.4a without problems and like the lay-out very much.
The only minor annoyance is that cuetools asks "One or more output file already exists, do you want to overwrite" when the only output file is the accurip log file.
I can see that for audio files it's a good precaution to prevent data-loss, but for the log file it's a bit overdone.
It's also a bit annoying 

Also a question:
Don't know much about the scripting possibilities yet, but if I learn more about it, would it be possible to write a script that checks a directory using 4 (or more) different pregaps?
I still have many old rips I would like to check but they are without a cue-sheet. So I would like to check those with a pregap of 0, 32,33 & 37.
(I know there are other pregaps out there (seen 1, 42)  but those are the most common ones.) 
This would make it much easier to batch check the directories. It would take some time, but at least I don't need to be at the computer to change the pregaps.


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-11-29 16:55:23
The only minor annoyance is that cuetools asks "One or more output file already exists, do you want to overwrite" when the only output file is the accurip log file.
You can use a template such as this: %filename%['('%unique%')'].accurip
This way accuraterip log will be always written to a new file. Of course, this way you'll have too many logs if you recheck your files often.

Don't know much about the scripting possibilities yet, but if I learn more about it, would it be possible to write a script that checks a directory using 4 (or more) different pregaps?
Try something like this:
Code: [Select]
if (processor.ArVerify.AccResult == HttpStatusCode.OK)
    return processor.Go();
if (processor.PreGapLength != 0)
    return processor.WriteReport();;
foreach (uint gap in new uint[3] {32, 33, 37})
{
  processor.PreGapLength = gap;
  processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
  if (processor.ArVerify.AccResult == HttpStatusCode.OK)
    return processor.Go();
}
return processor.WriteReport();
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ratscrew on 2009-12-01 21:04:02
sorry if this is the wrong place for this, but i have a quick question.

I use this tool to create .accurip files, to ensure that my large number of albums stored are accurately ripped.

Is there a way that i can drop in all my audio files (all contained in their own folders) but have the verification only proceed on folders that do not already contain the .accurip file.  I was hoping there was a way i could do this, so as to save time.  If this were the case, i could drop in all my folders, and the tool would only analyze and log the files it had not already done.

Is there a way to do this?

Thank you, and thanks for such a great tool!

Chris
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2009-12-01 21:25:02
I suppose it can be done using scripting. I will have to get back to you on this one.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kohlrabi on 2009-12-04 16:45:04
Awesome tool, I finally can convert all my Wavpacks with embedded CUEs to multifile FLACs with one click and create proper CUEs for them.

Greatly appreciated
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2009-12-06 10:51:03
I used the verification option and get the log below. Are tracks 21 and 23 OK ? What would be the reason for not being accurate on both offsets ? thanks

Code: [Select]
[Verification date: 05.12.2009 16:39:55]
[Disc ID: 004689d1-0473d2aa-67128417]
Pregap length 00:00:33.
Track    [ CRC    ] Status
01    [031123f2] (02/04) Accurately ripped
02    [c16fc029] (02/04) Accurately ripped
03    [62e77d64] (02/04) Accurately ripped
04    [820fd563] (02/04) Accurately ripped
05    [438de18f] (02/04) Accurately ripped
06    [b7cf0423] (02/04) Accurately ripped
07    [e1105962] (02/04) Accurately ripped
08    [2886560a] (02/04) Accurately ripped
09    [eb8694cc] (02/04) Accurately ripped
10    [4367803b] (02/04) Accurately ripped
11    [f3f1e101] (02/04) Accurately ripped
12    [a07d02c3] (02/04) Accurately ripped
13    [233ece73] (02/04) Accurately ripped
14    [6a7910d4] (02/04) Accurately ripped
15    [4b38205a] (02/04) Accurately ripped
16    [84b177d0] (02/04) Accurately ripped
17    [35d3db80] (02/04) Accurately ripped
18    [1407830f] (02/04) Accurately ripped
19    [82e33f1e] (02/04) Accurately ripped
20    [45d2830d] (02/04) Accurately ripped
21    [44637312] (02/04) Accurately ripped
22    [2301a1ba] (02/04) Accurately ripped
23    [e75761c2] (02/02) Partial match
Offsetted by -1918:
01    [44656175] (02/04) Accurately ripped
02    [b2009517] (02/04) Accurately ripped
03    [7b627e70] (02/04) Accurately ripped
04    [d20c9978] (02/04) Accurately ripped
05    [70812c6a] (02/04) Accurately ripped
06    [e82cef0c] (02/04) Accurately ripped
07    [ee044fdf] (02/04) Accurately ripped
08    [2d3dbf89] (02/04) Accurately ripped
09    [61c9c201] (02/04) Accurately ripped
10    [1c569e1a] (02/04) Accurately ripped
11    [d8080a86] (02/04) Accurately ripped
12    [a162ca55] (02/04) Accurately ripped
13    [36c82e0a] (02/04) Accurately ripped
14    [b2d39da2] (02/04) Accurately ripped
15    [ca77142e] (02/04) Accurately ripped
16    [cc1f89c3] (02/04) Accurately ripped
17    [9bdfbf02] (02/04) Accurately ripped
18    [237c042b] (02/04) Accurately ripped
19    [dee0e923] (02/04) Accurately ripped
20    [ec1ba7b7] (02/04) Accurately ripped
21    [b42a18ff] (02/04) Partial match
22    [15fc9344] (02/04) Accurately ripped
23    [ef410166] (02/02) Accurately ripped

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
--    [430A1C51]    [0315216C]    
01    [A5DC11F1]    [7F01FA1E]      CRC32  
02    [2C125DDE]    [50B52857]      CRC32  
03    [02281225]    [C16B41B7]      CRC32  
04    [C67D10DA]    [EE990696]      CRC32  
05    [52BA2C35]    [E980E500]      CRC32  
06    [3FF4C4B3]    [BB87C9DD]      CRC32  
07    [6A68072A]    [65976004]      CRC32  
08    [80370240]    [48958105]      CRC32  
09    [0D60425D]    [4182DDCE]      CRC32  
10    [5C311AEA]    [B902ED0C]      CRC32  
11    [9747D9B3]    [410141A3]      CRC32  
12    [A9275C40]    [B6A5B6D7]      CRC32  
13    [F5A6A9EA]    [60DEE102]      CRC32  
14    [679C0968]    [42455F1C]      CRC32  
15    [A155C855]    [F5CFCB8B]      CRC32  
16    [EEF39CA1]    [F3549D72]      CRC32  
17    [60193F01]    [263C8151]      CRC32  
18    [96938BCA]    [6DD4B9A2]      CRC32  
19    [AA86D8B8]    [395F2B6E]      CRC32  
20    [2F2D145B]    [A6836D84]      CRC32  
21    [99036794]    [DEE2FD23]      CRC32  
22    [1F32D768]    [AE2F1FFA]      CRC32  
23    [B2D7DB13]    [AF382247]      CRC32
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-12-06 12:19:39
prefab:
3rd pressing not yet in database (... or scratches ... last track is always harder to rip for various reasons too)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2009-12-06 13:39:52
sauvage78, thanks for your reply.
3rd pressing not yet in database
Aha did not think of that, it makes sense.
... or scratches ...
if it is scratched why does it match 2 other rips ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-12-06 13:46:42
prefab:
For me, the fact that it matches accurately on another pressing is an hint that it is not a scratch, but a problem with the first/last samples of the non-accurate tracks, because if it was a scratch in the middle of the song it would not match at all on the other pressing IMHO.

... and a problem with first/last samples of some tracks + an overall low confidency level (4) is likely due to a 3rd pressing, specialy if you're sure of your ripping settings & CD physical quality.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ninekithk on 2009-12-10 02:19:44
Great tool! With the tool I can de/encode bunch of HDCD single file image with embedded cuesheet into 24bit single track FLAC and get them nicely organised into folders automatically in several clicks.

Just wonder will it be possible to write tags in WAV files?
OR support encoding to AIFF with tags?
Thanks

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-12-13 23:34:11
I found a little bug in the EAC log analyzer:

For example when the log file actually contains two EAC logs (EAC appends logs to the .log file at each rip) and the rips were range copies of the whole CD (i.e. rip to one single file), then CUE Tools will treat both image CRCs as the first two tracks. This results in the CRCs being compared to the real CRCs of the first two tracks that are calculated by CUE Tools and added to the CUE Tools log.

It would be nice if CUE Tools could detect such EAC logs and either omit comparing the CRCs rejecting the logs, or use the last log in the file as the default (because we can assume it is the proper one corresponding to the audio file). Either way, the user should be noticed if there is more than one extraction log in the log file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lucsart on 2009-12-14 01:31:42
One of the most useful music tool i ever used, it works like a charm, i am not a tester but i have used it in many ways.

I use to convert various format, to a single solid flac + cue + log + accurip and the only thing i find annoying enough is that the first time i perform the command "encode" with "encode if verified" option selected it doesn't look-up for the cue on the freeDB, i have to stop it and re-do it again.

My options are "Image+cue" "lossless - flac" etc. etc.

If there is any "batch" reason not to perform such a first search with this option, can you at least put another option line like "encode if verified & with cue load" or anything like this, that will perform the right process?

Thank you

Lucsart

p.s. sorry for my english 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bregalad on 2009-12-14 18:59:54
Hi
I would like to know what is the status of this bug
That's why this wierdness showed up. This also made me realize that offsets that lead to partial matches should be listed separately.
Thanks, i'll fix it.

I thought it would have been fixed with version 2.0.4 but I see no mention of that in main post change log

I also wonder what happened to this idea
3.1) Include the version of CUETools in the log.

I haven't seen an answer of Gregory S. Chudov about this
Has it been rejected, postponed or forgotten ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nisto on 2009-12-17 05:06:09
A little suggestion about the cue sheet creator function...

Could you make a function that allows the user to grab titles from the filenames? Maybe create a little box where the user defines where the tracknumber, the title, and the extension name is. Like how mp3tag's "Filename to Filename" works. Maybe you could put this in its own tab inside of the application under "advanced settings", where the user can perhaps also edit the "PERFORMER" (and maybe more) part of the cue sheet.


This is from mp3tag's manual instructions about filename to filename, it describes how it works:

Quote
New filename pattern

Format string which is a combination of the parts defined in the format string above.
Example

Old filename pattern: (%1 - %2) %3 %4 %5 (%6)
Old filename: (Artist - Album) 01 EXAMPLE 2004 (COMMENT).mp3

New filename pattern: %5 (%1 - %2) Example '['%6']'
New filename: 2004 (Artist - Album) Example [COMMENT].mp3
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2009-12-20 14:48:22
On action "verify" CUETools will not update file tags with accurate rip information when the input is a single file with embedded cuesheet.
Can anyone confirm this?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: awatkins on 2009-12-22 23:37:17
CUETools is interesting, but there's not much left to be done here. I'm always more excited by doing something new, besides i'm a bit busy at work currently.

There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc. Thanks for ideas and suggestions, i will at least consider them.


Is there any chance of your adding higher-resolutions support (88/96K, 24bit)?

Thanks,

Alan Watkins
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2009-12-25 03:11:21
Is there any chance of your adding higher-resolutions support (88/96K, 24bit)?


What exactly would be the point? Those resolutions aren't supported by CDs, nor are they in the Accurate Rip database. What would you even do with them in CUETools?



And a question:

Can someone help me with some scripting that would get CUETools to move complete folders based on whether they were Accurately Ripped, not Accurately Ripped, or not in database?

Right now I can sort of achieve this for the CDs that were Accurately Ripped by re-encoding to a different folder, but the accompanying files (cover scans, etc.) don't move along.

I'm sure this would be a simple task if I understood the scripting!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2009-12-25 12:17:48
Thirtysomething pages ... is there somewhere a CLI user guide?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Trondis on 2009-12-25 16:13:22
Is there any chance of your adding higher-resolutions support (88/96K, 24bit)?


What exactly would be the point? Those resolutions aren't supported by CDs, nor are they in the Accurate Rip database. What would you even do with them in CUETools?



One use would be: If you rip LP's with Audition and save out a cue-sheet with Cuelisttool, then you could split and convert the wave-file to MP3 or whatever without downsampling the wav-file from 32 bits to 16 bits. I can do this in Foobar2000, but not Cuetools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2009-12-25 17:00:44
I wonder, isn't there an alternative to CD cue sheets for storing track position of vinyl rips? Why not split up the tracks right away in Audition?

Of course, I don't mind this being supported (except maybe that this weird (mis)use for cue sheets will eventually spread even more, leading to more weird feature requests in other applications and so on).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Trondis on 2009-12-25 18:40:22
I wonder, isn't there an alternative to CD cue sheets for storing track position of vinyl rips? Why not split up the tracks right away in Audition?

Of course, I don't mind this being supported (except maybe that this weird (mis)use for cue sheets will eventually spread even more, leading to more weird feature requests in other applications and so on).


I want to keep my original wav-file (or compress it to Wavpack, which keeps the track markings). If I split directly from Audition I get an extra set of wav-files which I then have to convert to MP3, and then tag it. The easiest way is to save out a cue-sheet with cuelisttool and split/convert it in Foobar2000. The alternative is to downsample to 16-bit and split/convert with cuetools, or mount the cue-file in a virtual disc and rip it with any CD ripper like dbPoweramp. In most cases I get the right tags right away if I do that. But it won't be in Accuraterip, of course.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2009-12-26 23:58:44
Is there any chance of your adding higher-resolutions support (88/96K, 24bit)?


What exactly would be the point? Those resolutions aren't supported by CDs, nor are they in the Accurate Rip database. What would you even do with them in CUETools?



One use would be: If you rip LP's with Audition and save out a cue-sheet with Cuelisttool, then you could split and convert the wave-file to MP3 or whatever without downsampling the wav-file from 32 bits to 16 bits. I can do this in Foobar2000, but not Cuetools.


If you can do it in foobar, then why does CUETools need to support it?

Cue sheets are meant to be a guide for CD burning software, not some bastardization of the lists of cue timings (which don't necessarily align to CD-sector boundaries) supported by other programs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-12-27 02:07:24
Hi, I have a little question: I've discovered (after some trying) the correct data length of an audio cd I've ripped some time ago (and can't no longer find at home...), so AccurateRip DB now can confirm the rip is accurate.
How can I save that value in the cue sheet so in the future I can verify that disc without enter the value manually each time in CueTools?
Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-12-27 03:25:53
buddhabar:
This info is not stored in the cue sheet but calculated from the EAC log, specially those with the recent EAC layout (those with TOC). AFAIK the only info related to data track in the cue sheet is the total tracks number in the DISCID which gives an hint of the presence of a data track if there is no EAC log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: buddhabar on 2009-12-27 18:57:09
Thanks for the reply sauvage78.
How can I create a "false" log with TOC so CueTools could recognize correctly the album each time?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-12-27 19:10:37
I don't know, I don't think it is possible & even if possible it is likely to be a manual task that is not worth the work. Personnaly I store Enhanced CD in a separate folder & I keep the datatrack length (when I know it) in a separate .nfo as I already use .txt for my .accurip files. I don't use logs at all, once I have checked if there is a datatrack I delete the log & create .nfo using the .accurip info. Nowadays knowing the datatrack lenght is the only use I have for logs but as most of my rips pre-dates the new EAC layout (with TOC) I decided to keep this info in a separate .nfo when I find it. I hope that someday cuetools will be able to check all possible lenght automatically, but I don't old my breath as it seems from his recent posts that Gregory is away from cuetools. Maybe it is possible to create a TOC from .cue ... I don't know enought about TOC as I never used it. But even if possible it will miss the extra data track lenght & you will have to add it manually which will be long & painfull. Editing LOGs is never a good idea anyway, even for this use IMHO.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bregalad on 2009-12-27 21:58:47
Can someone help me with some scripting that would get CUETools to move complete folders based on whether they were Accurately Ripped, not Accurately Ripped, or not in database?

Right now I can sort of achieve this for the CDs that were Accurately Ripped by re-encoding to a different folder, but the accompanying files (cover scans, etc.) don't move along.

you might use foobar2000 for this
CUETools check the rips and write corresponding tags to the files
Then you open these files in fb2k, sort them according to these tags and finally move each category using a different method for each
I use the tag and move features of fb2k a lot, it is very powerful and works perfectly even on Linux through Wine
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bregalad on 2009-12-27 22:09:32
I think I found a bug in CUETools v2.0.4a
I can't get the batch mode summary in the log

A friend of mine have it simply when changing the settings to verbose mode for log and keep all the rest to default (example D:\Music\DEATH\Death  - Individual thought patterns.cue: offset 97, rip accurate (21/25).  )
The only possible explanation I see would be that this feature does not work under XP (but works on Vista)
Anyone else having trouble with this under XP ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: alexander038 on 2009-12-28 13:54:56
Is there a daily limit to the AR database because yesterday i got this log more than five times with different files..
Code: [Select]
[Verification date: 27-12-2009 22:43:59]
[Disc ID: 00175a88-00a8bb2c-820f6a09]
Database access error: BadRequest

Track   [ CRC32  ]   [W/O NULL]   [  LOG   ]
--   [600ABA4A]   [4C4AEEFB]    W/O NULL
01   [F478E689]   [A9A4694D]  
02   [F268F156]   [6DDBF686]  
03   [0DCE2103]   [F1E5A46F]  
04   [6C866626]   [64C896AD]  
05   [00A9F921]   [30F760AC]  
06   [ABB29899]   [6B0264A0]  
07   [BA5344B0]   [BBFADDD1]  
08   [2DC58AAF]   [6A10EDC0]  
09   [08E518C6]   [C4D6E97A]


And today things were all fine
If there is a limit could somebody give me more information about it?

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a3aan on 2009-12-28 14:43:24
I noticed the same.

...
Database access error: BadRequest
...

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2009-12-28 15:14:24
It already happened to me once & a few hour later everything was OK.
I think it means that the database is temporary offline for some reason, most likely maintenance I guess. As long as it comes back quickly it is nothing to worry about IMHO.
It seems to happen a few hours a few times by month & I guess only Spoon exactly knows what happens in these cases. Sometimes forums go offline for maintenance too, it seems very similar to me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2009-12-28 17:16:56
>If there is a limit could somebody give me more information about it?

Yesterday the AccurateRip server was being maintained. Will also go down this week for half an hour.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: alexander038 on 2009-12-28 19:07:52
>If there is a limit could somebody give me more information about it?

Yesterday the AccurateRip server was being maintained. Will also go down this week for half an hour.

Thank you spoon for the info
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-01-01 19:02:48
Issue:

I get the familiar "CUE Tools has encountered a problem and need to close" with every 2.x version. Not with latest stable.

- OS: XP MCE
- .NET version: Tried version 2 with update as specified, and also upgraded to 3.5. Same results.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-01-02 13:36:34
I get the familiar "CUE Tools has encountered a problem and need to close" with every 2.x version. Not with latest stable.

- OS: XP MCE
- .NET version: Tried version 2 with update as specified, and also upgraded to 3.5. Same results.

I am seeing the same problem on one of my PCs. It is an AMD Athlon XP 2600+ with a Finnish language XP Home OS (SP2). CueTools crashes immediately on startup. I have all dotnet and c++ updates installed.

The same happens with all 2.x.x versions. Only the "stable" v. 1.9.5a works fine.

The v. 2.0.4a works fine on all other PCs that I have tried: an old Intel P4 with English XP Pro, a new AMD Phenom II with English XP Pro (32-bit) and also an AMD Athlon XP 3200+ with English XP Pro and English Windows 7 Ultimate 32 bit (I'am evaluating Win 7 on this PC).

Could the problem be caused by some kind of incompatibility with the Finnish OS? All other PCs have an English OS.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-01-02 13:48:08
Could the problem be caused by some kind of incompatibility with the Finnish OS?



My XP MCE with the same problem is English.

Furthermore, I just managed to get it working with a Norwegian XP installation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-01-02 14:07:27
OK, some requests and and questions/issues, all related to the AccurateRip verification functionality only.
Version 2.0.4 tried, on some ~ 70 folders in batch.



Issues/questions first:
-> Is the CRC32 "W/O NULL" done by setting offset for the entire disc so that it starts at first one?
IOW, if I want to scan my library for CDs that are identical modulo offset, then -- at least if there are sufficiently many zeroes in the beginning or at the end, and no data tracks -- it is necessary and sufficient that all these match?
Edit: And is the first one a CRC for the entire image, with the above holding true?

-> Some discs are allegedly not present in the database, even if they at time of ripping got confidence levels in the thirties. (dBpoweramp used, no single tracks needed re-ripping.)

-> Is it supposed to work well with dBpoweramp-esque HTOA track 0's?




Then requests:

-> CLI to accept folder name as input

-> A file report using ">" in the CLI.

-> In the batch GUI version, write the content of the report window as a file, with each line written as done (in case of crashes -- the process takes overnight here ...) or in the very least a "mark all".

-> The output giving, say "confidences 31 to 45" rather than referencing just the first file

-> In case of files already present: A "Yes to all" and "No to all" button. Or an "overwrite: [_] yes [_] no [_] ask" option before running.  And, in case no, report "skipped".

-> Drag'n'drop mode: A checkbox for "add" (vs "replace"), and the opportunity to mark and delete.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-01-11 00:11:11
Just found my old test notes, I had completely forgotten about them. Now I remember that I promised to report back some bugs I had found (+just found lots of new ones). Well, better late than never. Sorry about that.

Some of these points are already reported/requested by me (no answers), and there might be some things that others have reported/asked, sorry if there's duplicates.

Bugs/problems/usability/etc.: (hopefully this is readable, I split long lines)
Code: [Select]
1. Links in the about dialog doesn't work.

2. "Formats", "Decoders" and "Scripts" setting tabs doesn't have add/remove buttons like the "Encoders"
setting tab has.

3. Main window profiles dropdown menu: changing the profile doesn't change the "basket" icon to the
selected profile.. though the dropdown button shows the basket beside the selected profile name.

4. "Only if found" selected saving bug.

1) Clear CUETools appdata folder, i.e. start with "clean" settings before opening CUETools.
2) Start app and select e.g. "my music" folder so that you can access the "Action" settings in the main
window.
3) Select "Verify" and "only if found"
4) Open settings and click OK

= "only if found" reverted back to "default".

5. It's a bit confusing what is saved to a profile in the main window. The "Extra" settings "pregap" and
"data track" settings are global (gets changed to every profile) while "offset" is saved per profile. (Ok
ok, "pregap" and "data track" settings are in fact "session" only settings, no point of saving them, right?)

Same thing with the "audio output" settings; the 1st and 2nd dropdown selection boxes and "slider" settings
are global though the "lossless/lossy/hybrid/none" setting is per profile.

Also, "correct filenames" "mode" settings are global.

6. Why isn't the "format" (1st) dropdown selection box nor "compression slider" not disabled when "none" is
selected in the "audio output" section?

6.1. "Unhandled exception" bug when changing the "compression slider" setting while "none" selected in the
"audio output" section.

7. Is the small file browser "placeholder" seen in the far left designed to be that way? There's a very
small scroll button(s) seen in the bottom of it and one can select folder/files even though the browser is
"hidden".

8. "Data track" field disabled bug.

1) Clear CUETools appdata folder, i.e. start with "clean" settings before opening CUETools.
2) Start app and select e.g. "my music" folder so that you can access the "Action" settings in the main
window.
3) Change "audio output" to "none"
Side note: notice how "embedded" in the "mode" gets disabled. Still selected.. possible problem if
not noticed and changed before clicking "Go"?
4) Select "verify" in the "action" and back to "encode"
-> "Data track" gets disabled.
5) Select "lossless"

= "Data track" still disabled. Different types of main window "setting changes"/selections either does
or doesn't enable the "Data track" field, it seems that there's no logic to it at all.

9. "Empty" profile bug.

1) Clear CUETools appdata folder, i.e. start with "clean" settings before opening CUETools.
2) Delete one by one all profiles (except the default, impossible to do that).
-> profile dropdown lists only default profile.
3) Close app and start it again.

= Profile dropdown lists default profile AND an empty profile with no name. Happens because the empty "Profiles="
setting in the "settings.txt" is parsed incorrectly?

4) Select the "empty" profile and Close app.
-> A "profile-.txt" file is created in the appdata folder for the empty profile.

10. ReadMe.txt old/incorrect filename and path formatting variables.

1) Clear CUETools appdata folder, i.e. start with "clean" settings before opening CUETools.
2) Set the "logname format" to "%F.accurip" (without quotes).
-> that setting is changed in the settings.txt after OK clicked.
3) Do verify operation.

= The file created is "%F.accurip" (without quotes).

4) Close app and restart.
5) Open settings dialog.
-> Notice how the "logname format" is now "%filename%.accurip" (without quotes).
6) Click OK.
-> Only after this, that setting is changed in the settings.txt.
7) Open settings dialog.
8) Set the "logname format" to "%Y.accurip" (without quotes).
-> that setting is changed in the settings.txt after OK clicked.
9) Close app and restart.
10) Open settings dialog.
-> Notice how the "logname format" is still "%Y.accurip" (without quotes).

So, it seems that only the old "%F" is detected as a "failsafe" (updating from previous versions), AND
only when opening the settings dialog.

11. "Verify" profile used when running "CUETools.exe /verify *.cue" + other oddness.

Prerequisite: a rip of an album that is not present in the AR database.

1) Clear CUETools appdata folder, i.e. start with "clean" settings before opening CUETools.
2) Run CUETools.exe /verify "filename.cue"

= "Error: Object reference not set to an instance of an object." Error when no appdata folder
settings.txt file present?

3) Open and close app.
-> "settings.txt" created, no settings file for the "Verify" profile created.
4) Run CUETools.exe /verify "filename.cue"

= Again, "Error: Object reference not set to an instance of an object.".

5) Open app and settings, enable the "In source folder" under "Write AccurateRip log" setting, click OK
and close app.
6) Run CUETools.exe /verify "filename.cue"

= No errors, CUETools makes a "only if found" AR verification. Notice that there's no "Verify" profile
file at all!! And the "settings.txt" (=default profile + some general settings (which are not in other
profile files)) file has both "DefaultVerifyScript" and "Script" set to "default", which means that
CUETools has some "internal" default settings, at least, for the "Verify" profile.

7) Open app, change to "verify" profile and back to "default", close app.

= Now, for some reason, "settings.txt" has "DefaultVerifyScript=only if found" (no change to "Script"
setting). The created new "profile-verify.txt" file has "DefaultVerifyScript=default" and "Script=only
if found". So, suddenly default profile "inherited" the "DefaultVerifyScript" setting from the "verify"
profile "Script" setting!?

8) Open app, check "action->verify: used script" from both "default" & "verify" profiles.

= Both profiles have "only if found" scripts set with the "verify" action! Look at the point 7 result
text, the 2 settings are different, why is both profiles using "only if found" scripts?!

9) Close app.

= Oddness continues: now the "settings.txt" profile "Script" setting is changed to "only if found"!?

10) Open app, select "verify" profile, delete it and close app.

= "profile-verify.txt" is not deleted though "verify" is removed from the "Profiles" setting in the
"settings.txt".

11) Open app, change the "verify" action script to "default", close app.

12) Run CUETools.exe /verify "filename.cue"

= Still using the "only if found" script when checking!

13) Delete "profile-verify.txt" file from the appdata folder.
14) Run CUETools.exe /verify "filename.cue"

= Still using the "only if found" script when checking! Again, "internal" default settings?

15) Open app and settings, disable the "In source folder" under "Write AccurateRip log" setting, click
OK and close app.
16) Run CUETools.exe /verify "filename.cue"

= Again, "Error: Object reference not set to an instance of an object.". So, settings in fact read from
default profile file and from "internal" default settings?


Bug/problem summary from this point only:

1. "CUETools.exe /verify" doesn't work without settings.txt file and when "In source folder"
setting is set to off.

2. Using of "internal" profile default settings.. + using/mixing those settings with settings that
ARE saved to a file (e.g. "ArLogToSourceFolder" read from default profile, "only if found" script
setting read from "internal" default setting AND/OR from saved "verify" profile (ignoring the
"ArLogToSourceFolder" from that same profile)). Messy, eh?

3. "DefaultVerifyScript" and "Script" settings jumping across profiles & across those settings.

4. Profile files not deleted when deleting profiles from the GUI.
Maybe the profile/settings system needs a rethink/redesign? I'm really sorry to say this but, nicely put, currently it's a big mess (judging from black-box testing). There might be more bugs lurking because of the profile/settings design. Points 4, 5, 9, 10 & 11 attribute to this concern.


Feature reqs/misc.:

12. GUI beautification(?): CUETools started with /verify and filename -> window has no "proper" title bar (not really needed I guess) and shows "default" VS icon in the taskbar.

13. GUI beautification(?): "Tagging" settings tab: "Album art", "resize if resolution >" text field goes slightly over the above input field.

14. "Set read-only attribute to AR log file" feature in the options? Or how to amend the "only if found" script to do it?

14.1. Is there a manual of using the scripting feature? Kind of pointless to offer a script editing/adding feature if there's no language syntax nor method names to call for documented?

15. Include the version of CUETools in the log. IMO, it's always a good practice to log the app name+version.


Questions/notes:

16. Just noticed that there's an update to CUETools, the 2.0.4a version. I've been using 2.0.4 for some time.. with the annoying "logname setting not saved" bug (I wrote this part first.. all bugs/etc. listed in this post have been tested with the latest 2.0.4a version). Completely missed that ("silent") update. And "check for updates" in the app failed to notify me.  Version value problems? (from the "2.0.4a" version package: CUETools.exe: 2.0.3.1, settings.txt: Version=203 and motd.txt: CUETools 2.0.4) Also there's no mention in the changelog that you made the "only if found" script to work with the "CUETools.exe /verify" (=changes to profiles system). Found it by accident just now when testing the new bugs I found. Maybe other people don't like to read changelogs but I do. I don't want to guess what's changed, or being surprised by them (especially if that happens later after they have already affected my "process").

17. What's the situation with CUETools? Are you still developing it? IIRC you wrote that you have moved on to other projects and you see CUETools ready? IMHO it's weird that the 1st post mentions that "Current stable version: 1.9.5a", and the last version changelog says "Experimental profiles system". Is the 2.0.4a still an unstable/experimental version? Also, maybe an installer to finish off the app? Manual (online)? E.g. the "%filename%['('%unique%')'].accurip" should be documented (picked that out from this topic). IMHO, lots of polish needed to call this app ready.

18. Does CUETools use the local AR "cache" (it's sometimes a stale cache) in "*\Application Data\AccurateRip\AccurateRipCache"?

19. It seems that "ArCueDotNet.exe" does not/can't use any profiles, is this true?



P.S. Congrats on the very high number of downloads, CUETools is a success.

P.P.S. Sorry about this "bomb".. I wouldn't have done this much free work for a program I don't like. (Here's hoping that it doesn't go to waste.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-01-12 21:48:05
-> Is the CRC32 "W/O NULL" done by setting offset for the entire disc so that it starts at first one?
IOW, if I want to scan my library for CDs that are identical modulo offset, then -- at least if there are sufficiently many zeroes in the beginning or at the end, and no data tracks -- it is necessary and sufficient that all these match?
Edit: And is the first one a CRC for the entire image, with the above holding true?


Hmmm ... might it be that the range of offsets should have been bigger?

What is this variable called, and what do I need to compile the source code? (As mentioned before, it crashes on my computer, but maybe a locally compiled .exe will run?)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-01-13 09:34:56
-> Some discs are allegedly not present in the database, even if they at time of ripping got confidence levels in the thirties. (dBpoweramp used, no single tracks needed re-ripping.)

Sounds a bit familiar, have you seen this topic (http://www.hydrogenaudio.org/forums/index.php?showtopic=77369)? Related?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-01-13 17:35:21
Sounds a bit familiar, have you seen this topic (http://www.hydrogenaudio.org/forums/index.php?showtopic=77369)? Related?

Interesting. I didn't realize the offset field in CUETools worked that way, so having tried Gregory's advise, I see that too small offset is not the issue.

PS: Sweet avatar
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2010-01-14 02:48:33
Can someone help me with some scripting that would get CUETools to move complete folders based on whether they were Accurately Ripped, not Accurately Ripped, or not in database?

Right now I can sort of achieve this for the CDs that were Accurately Ripped by re-encoding to a different folder, but the accompanying files (cover scans, etc.) don't move along.

you might use foobar2000 for this
CUETools check the rips and write corresponding tags to the files
Then you open these files in fb2k, sort them according to these tags and finally move each category using a different method for each
I use the tag and move features of fb2k a lot, it is very powerful and works perfectly even on Linux through Wine


Brilliant! I can't believe I never thought of this. I use foobar2000 religiously, but very early on I turned off all the tags that CueTools adds and never remembered that they are there.

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-01-27 22:40:00
There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc.
Hi Gregory, any chance of a build with ALACEnc ? I have been using the latest version from sourceforge and Flake and ALAC work very well, but as I could not get the C part to compile I cannot process APE files (must decompress them to WAV first). Cheers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-01-27 23:39:10
As soon as i can. A bit overwhelmed at work right now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-01-28 06:57:49
As soon as i can. A bit overwhelmed at work right now.
The APE file is not a blocking issue, thanks for all your work so far. Cheers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: frozenspeed on 2010-02-02 15:05:32
Is there a way with fb2k & the accuraterip tags cuetools makes, to tell if a rip is not accurate? You know similar to how it says it in the batch log "rip not accurate"?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-02-04 00:08:22
Seems that CUETools refuses to generate cuesheets for single-track albums (or query AccurateRip).
Is there any setting I might have screwed up, or is it a bug?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-02-04 12:43:19
Seems that CUETools refuses to generate cuesheets for single-track albums...

I reported that problem when the v. 1.95 was new: http://www.hydrogenaudio.org/forums/index....st&p=618837 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=618837)

Gregory fixed it in 1.95a: http://www.hydrogenaudio.org/forums/index....st&p=620986 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=620986)

I have not tried single-track albums since then (I have only two such CDs), but could the problem have sneaked back in?


Or are you tying to create a cue sheet for a single audio file that doesn't already have a cue sheet? That is not possible because the folder must contain at least two files in the same format before the "album" appears in CUETools' internal browser.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-02-04 12:59:10
are you tying to create a cue sheet for a single audio file that doesn't already have a cue sheet? That is not possible because the folder must contain at least two files in the same format before the "album" appears in CUETools' internal browser.


Yes. I drag and drop the folder. No matter whether I try to create cuesheets or verify, nothing happens.

The use of a cuesheet for a single track album, is to have only .cue files in my media player library, slashing a zero from a file count of some 70 K.
(My albums are organized as one folder per physical CD.)



Using 2.04a.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ggg on 2010-02-05 22:13:52
Heello
After i have installed .Net Framework 2.0 & that C++ shit i received another bug message

See the picture below :

(http://img341.imageshack.us/img341/3363/hydrogen.jpg)

Is this program really working ???
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: kisli on 2010-02-05 22:30:08
Is there a reason you're not using the latest version?
http://www.hydrogenaudio.org/forums/index....showtopic=66233 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ggg on 2010-02-06 10:13:28
I tried first the latest versiion but it gave me the same mistake.
& i tried again with 1.9.5  , because it writes its the latest stable versiion
but the problem remains...
some opinions whats the reason ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-02-06 10:24:10
A quote from the above link:
Quote
IMPORTANT: .NET Framework 2.0 (SP2) required.

Did you install the SP2 update?
What is your Windows version?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-02-06 11:13:23
I don't think i've seen such error before. Please, give more details. When exactly does it appear, etc.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-02-06 11:18:02
Yes. I drag and drop the folder. No matter whether I try to create cuesheets or verify, nothing happens.

CUETools should be able to process cue sheets for one-track albums, at least i test it on Mike Oldfield's Amarok
It cannot automatically create cue sheets for a single file, but you can create it manually, it's very easy: all one-track cue sheets (minus pregap) are the same:
Code: [Select]
FILE "Image.wav" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ggg on 2010-02-06 11:40:23
Windows Service Pack 2 needed   
I have neither SP1 nor SP2
.Net Framework 2.0 needed
some C++ needed
Sp1 needed
sp2 needed
Imho these are to many limitations , that require to be accomplished  in order to work correctly..
no thanks , for cue-ripping i will switch to Foobar 2000...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-02-06 12:26:40
Gosh. Well, i'm sorry, but i just can't support 10 years old operating systems that never have been updated. Updating to a latest service pack is always a good idea, even if you don't need CUETools
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-02-20 02:04:21
OK, seems like some moderator deletes wishlist entries (s)he disagrees with 


Anyway, I wish for better features to (I) retro-check rips, and (II) pairwise-compare rips. Looks like if there are non-null samples at the very end of a live recording, then the CRCs of two different pressings not found in AccurateRip, will all be different.


So for topic (II), what about:
- When two folders are dragged and dropped (could be restricted to the case where there are exactly two there!), what about checking how far they agree, starting from first nonzero sample? That would reveal duplicates not found in AccurateRip, as well as the case where one release has one or more bonus tracks (numbers > N), and the other CD consists of the first N tracks, bit-identical modulo offset.
- When reporting the results of this, report whether they are identical up to and including track N with or without the end-of-CD truncation that is done by AccurateRip-CRCs.


For topic (I):
- There are cases where the appropriate disc ID is known, for example does dBpoweramp write it to tag (I don't know if EAC does, but it might be?). So, the option to read disc ID from tag, or maybe even from discid.txt in the folder to be checked, would certainly help. (In the presence of data tracks might be some issues concerning whether the audio starts at track 1 or 2 though -- that could be checked by just comparing to the AR-CRC for track n+1 provided the first track has number 1.)


And finally, relevant to both (I) and (II):
- If the number of folders is two, scan either with its CUETools-calculated TOC [or ID read from files], and whenever one is failed to verify as accurate, then scan with the other's TOC [or ID read from files].
This covers cases where two CDs differ only in track separation. There seem to be a few such cases where there are no sign of remastring from analogue tapes, but where the knife between two tracks is set slightly different.


Edit: And thanks for the info on single track discs. I can of course create it manually yes, and maybe I am the only one who doesn't even know how many single-track discs I actually have in my collection?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-02-20 02:12:19
OK, seems like some moderator deletes wishlist entries (s)he disagrees with 

No, just that "some moderator" split it off because it was going too far off-topic but failed to provide a link (http://www.hydrogenaudio.org/forums/index.php?showtopic=78167).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-02-20 02:37:01
OK, seems like some moderator deletes wishlist entries (s)he disagrees with 

No, just that "some moderator" split it off because it was going too far off-topic but failed to provide a link (http://www.hydrogenaudio.org/forums/index.php?showtopic=78167).

OK; in that case, dare I reiterate the wishlist item at http://www.hydrogenaudio.org/forums/index....st&p=683133 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=78167&view=findpost&p=683133) ? Need not be in log file (if log file is set to mimic EAC actions), might as well be a pop-up if precisely two folders are dragged-and-dropped.

This is not about what EAC does and doesn't, it is about this application (edit: CUETools, that is) as of now being my most efficient way of finding two folders whose audio matches modulo offset. Scan a library, scan accurip files pipe grep the "--" string, extract the two image CRCs; if both match (well they probably don't, as I have removed a few of them before starting to use CUETools), then definitely equal, if the latter matches, then well, probably still equal (but have a look).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: avanegmond on 2010-02-21 10:08:08
Yes. I drag and drop the folder. No matter whether I try to create cuesheets or verify, nothing happens.

CUETools should be able to process cue sheets for one-track albums, at least i test it on Mike Oldfield's Amarok
It cannot automatically create cue sheets for a single file, but you can create it manually, it's very easy: all one-track cue sheets (minus pregap) are the same:
Code: [Select]
FILE "Image.wav" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00



If it is just for creating cue files based on directory contents the tool cuecreator (http://sourceforge.net/projects/cuecreator/) is very handy as well.

-
aleg
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: brycemc on 2010-02-22 03:03:28
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!

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-02-22 04:24:51
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-02-23 09:29:22
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
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-02-23 11:24:34
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-02-24 00:29:05
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-02-24 20:12:35
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-02-28 22:10:21
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/ (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 (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf), x64 version (http://www.microsoft.com/downloads/details.aspx?familyid=BD2A6171-E2D6-4230-B809-9A8D7548C1B6&displaylang=en). 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 (http://www.cuetools.net/install/CUETools_2.0.5.rar)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-02-28 23:21:12
Nice to see that the development is still going on! Are you able to comment on the points in my old post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=679211) 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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-02-28 23:23:52
I didn't fix any of that yet, but i haven't forgotten about it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: 870421dy on 2010-03-02 06:46:28
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!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bregalad on 2010-03-02 20:08:04
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 ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-02 20:14:42
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 (http://db.cuetools.net/about.php).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-02 20:27:35
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: punkrockdude on 2010-03-02 20:53:20
Thank you so much for this application! It helped me split some single image flac files and create new .cue file. Amazing! Regards
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2010-03-02 21:25:26
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?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-02 21:40:55
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2010-03-02 21:53:03
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-02 22:02:27
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2010-03-02 22:12:27
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
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-02 22:14:22
Great!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: 870421dy on 2010-03-03 05:38:44
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!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-03-03 15:32:11
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-03 22:56:20
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-03-04 00:44:13
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?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-03-04 12:32:01
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.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2010-03-04 13:27:32
Thanks.

BTW, i just repaired my first real rip


Is there the possibility to "repair" a perfect rip from a slightly different pressing?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2010-03-06 08:23:40
I think you refer to this case.

Code: [Select]
[Verification date: 5/3/2010 9:11:30 μμ]
[Disc ID: 001baed9-01254f28-b10ca40e]
Pregap length 00:00:33.
CUETools DB: disk not present in database.
Track [ CRC    ] Status
 01 [8f383bae] (200/200) Accurately ripped
 02 [0386fda4] (200/200) Accurately ripped
 03 [330d8334] (200/203) Accurately ripped
 04 [2d939a3a] (200/200) Accurately ripped
 05 [fc6dc445] (200/200) Accurately ripped
 06 [a8fcb19d] (200/200) Accurately ripped
 07 [a3fbda10] (200/200) Accurately ripped
 08 [414bd0e6] (200/200) Accurately ripped
 09 [f8129bf6] (200/200) Accurately ripped
 10 [c77429b7] (200/200) Accurately ripped
 11 [2f34940d] (200/200) Accurately ripped
 12 [d7a595bd] (200/200) Accurately ripped
 13 [7c490c6d] (200/203) Accurately ripped
 14 [dc6a17f7] (04/204) Accurately ripped

Track [ CRC32  ] [W/O NULL]
 -- [2F8D3881] [022591A4]
 01 [F74F64C7] [BE4D0CE8]
 02 [EDB1FCF2] [2AE6B70F]
 03 [1CF4C84B] [C0344AEB]
 04 [FC3F00E3] [BF913898]
 05 [FA7CB5E3] [DD0A648A]
 06 [729F6E5E] [D9962861]
 07 [B9552752] [AECDA733]
 08 [84FCD495] [12578873]
 09 [6870AD1C] [0BA81E91]
 10 [350404A0] [314905F0]
 11 [A50DA9BA] [40AD22CD]
 12 [04477BEE] [B6D305CD]
 13 [E175A42E] [809A1168]
 14 [EBD1F5FB] [FA882052]

This disc ripped with different dvd drives / eac versions with always the same results. It's not really important to be corrected because the disc I have is an official release and probably not damaged, but is there any chance in future versions, Gregory?

PS. I corrected 3 bad rips until now, thanks 
PS2. I also report a bug that causes an exception with empty message. That's when submit option from the combo box is enabled. x86 version with win2k3 x64.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: moikboy on 2010-03-06 16:16:35
Hi,

Im using cuetools for verifying my rips via accuraterip. It has been working perfectly, until now - because ive found a strange anomaly

I was trying to verify a rip with its original cuesheet, but cuetools did not find it in the database. Then, i tried verifying with a test cuesheet (which contained the files after each other), and now, the program did find it, and verified my rip as accurate (02/02). I think this has something to do with the pregaps in the original cuesheet ("INDEX 00"'s), which werent included in my test sheet.

Does this mean, that when previously, cuetools did not find a certain release in the db, it could have been found and verified, but without caring about pregaps? :S
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-03-06 16:38:00
Mark the folders -- not the files therein, but the folders themselves -- and drag + drop.

What if the folders are not in the same parent folder? Same problem like before.

Hmmm, I remember adding multiple cue sheet to the drag'n'drop window... or where they in the same folder? I can't remember.

@Gregory: I have a feature request, please.

The Windows Explorer / Windows / general GUI standard uses the CTRL modifier as a "copy" command when dragging and dropping items. Normal drag'n'drop without a modifier is merely "move". The CTRL modifier has a certain function associated with it. It's a sort of a multiplier, it's "adding something more".

So it would be nice if CUETools would also behave make use of this modifier. Normal dragging and droppping of one ore more items will replace the current list of items but using the CTRL key as a modifier could add those items to any existing ones. Hey, even a "non-standard" behaviour would be nice: dragging and dropping while holding CTRL will not only add non-existing items to the list, but will also remove already existing items from the list. Making the CTRL modfier not an xor. Also selecting an item in the drag'n'drop list and pressing the DEL key will not remove that item, that should also be added to the drag'n'drop mode.

And then the standard cursor when the items are being dragged above the drag'n'drop zone of CUETools always has a plus sign... I don't know all the mouse cursor bitmaps Windows has to offer, but there surely must be a few to pick from to make the cursor change its looks when the user is holding the CTRL key. Just like Windows Explorer changes the mouse cursor depending on what modifier keys the user is holding.

PS: Are you planning on integrating the CUE Ripper into the main app? It would be great.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-07 08:36:05
Is there the possibility to "repair" a perfect rip from a slightly different pressing?

If by slightly different pressing you mean a pressing with different offset, than CUETools can still correctly repair it taking offset into account. It will not change offset of your rip. If your rip differs only in offset from the one in database, then nothing will happen.

If you mean can you damage a rip by "repairing" it using a record from DB that corresponds to a bad rip, then yes, you can. CUETools doesn't know which version is correct. It just makes your rip the same as the one that was submitted, so be careful. It's up to you to decide if your rip needs fixing, and which confidence number do you trust.

This disc ripped with different dvd drives / eac versions with always the same results. It's not really important to be corrected because the disc I have is an official release and probably not damaged, but is there any chance in future versions, Gregory?

Chances of "fixing" something depend more on the growth of the database than on future versions. If someone submits the other version of this rip, you will be able to fix your rip using current version, but i wouldn't fix what isn't broken.

PS. I corrected 3 bad rips until now, thanks 
PS2. I also report a bug that causes an exception with empty message. That's when submit option from the combo box is enabled. x86 version with win2k3 x64.

3 rips - wow, that's great news, i was waiting in anticipation for such reports. That means CUETools DB isn't useless after all
Any pattern to this exception? Does it always appear on the same discs? Can it be network related (how stable is your connection)?

Does this mean, that when previously, cuetools did not find a certain release in the db, it could have been found and verified, but without caring about pregaps? :S

I think this really is an anomaly. My guess is that there were two pressings of this CD, one with pregap and one without.

The Windows Explorer / Windows / general GUI standard uses the CTRL modifier as a "copy" command when dragging and dropping items. Normal drag'n'drop without a modifier is merely "move". The CTRL modifier has a certain function associated with it. It's a sort of a multiplier, it's "adding something more".

Specially for you, http://www.cuetools.net/install/CUETools_2.0.6.rar (http://www.cuetools.net/install/CUETools_2.0.6.rar)

PS: Are you planning on integrating the CUE Ripper into the main app? It would be great.

I don't see the point. They are integrated in a way, but the ripper obviously needs a separate UI. Of course i could add a button to CUETools which would launch CUERipper, but isn't it easier to just have separate shortcuts for them on your desctop/startmenu or quicklaunch?

P.S: If you downloaded 2.0.6 right after this post, then it probably crashes with null reference error on conversion. Just re-download it please. Sorry.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2010-03-07 13:09:40
Any pattern to this exception? Does it always appear on the same discs? Can it be network related (how stable is your connection)?


It's always reproducible with (verify OR fix) AND submit on every disc that can be found in accuraterip base but not in cuetools db. The output file gets written correctly and then this exception appears. It cannot be a network related issue. If it was I think I would get a BadRequest  msg in the output file.

PS. If I recall well, it was reported that about 1000 bad samples were corrected in one of the 3 discs. 

Edit: I also have VS2008 installed with its libraries.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-03-07 16:33:07
Issue:

I get the familiar "CUE Tools has encountered a problem and need to close" with every 2.x version. Not with latest stable.

- OS: XP MCE
- .NET version: Tried version 2 with update as specified, and also upgraded to 3.5. Same results.



Issue does not disappear with 2.0.6. (Will probably work on another computer with a different XP.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-03-07 23:35:35
The Windows Explorer / Windows / general GUI standard uses the CTRL modifier as a "copy" command when dragging and dropping items. Normal drag'n'drop without a modifier is merely "move". The CTRL modifier has a certain function associated with it. It's a sort of a multiplier, it's "adding something more".

Specially for you, http://www.cuetools.net/install/CUETools_2.0.6.rar (http://www.cuetools.net/install/CUETools_2.0.6.rar)


Wow, that was quick! Even the mouse cursors are done and DEL works, too.  Thanks.

But one minor issue detected: I have to hold CTRL before I drag another file out of the Windows Explorer. Holding or releasing CTRL while holding the left mouse button, i.e. while holding the file(s) in my mouse hand, does not switch between "add" and "replace". Windows standard is that you can still switch between the modes "move to" (shift), "copy to" (ctrl) and "create link in" (alt) while dragging the files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Joeyeti on 2010-03-08 08:52:58
Hi Greg,

first and foremost - congrats on a superb utility! Using CueTools for half a year now, perfect!

One question - I tried to use the %directoryname% and %path% variables in the Output template (version 2.0.4a) and they give me the same - the full path of the original FLAC files when I want to transform them to MP3 on a different drive.

I thought the %directoryname% would only give the name of the directory the source files are in (not the full path as in %path%)?



Thx!

Joe
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-08 09:00:57
One question - I tried to use the %directoryname% and %path% variables in the Output template (version 2.0.4a) and they give me the same - the full path of the original FLAC files when I want to transform them to MP3 on a different drive.

Try something like this: $directory(%path%,1)\%filename%.cue or $directory(%path%,2)\%filename%.cue
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-03-09 19:20:52
But one minor issue detected: I have to hold CTRL before I drag another file out of the Windows Explorer.


More precisely, the modifier key is only checked once when the mouse cursor enters the CUE Tools window.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-03-11 12:40:25
Hi all, thanks for this fabulous software, I badly needed something to properly cut flacs into alac so I can use it with itunes, and mantain gapless playback. However, I have two important questions I didn't find answered anywhere:

- For mp3 files, is CUETools capable of lossless split (no re-encode)? If not, are there any plans to develop it? The only alternative for proper mp3 lossless split I know is pcut...

- when encoding to m4a, what is the difference between each encoder (libALAC and ffmpeg ALAC)?

thank you for your time and this tool!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-11 13:04:19
CUETools can not split or transcode mp3. Lossy formats are supported only for output, and only via external encoders.

libALAC is CUETools own ALAC encoder. ffmpeg is an external encoder, for it to work you need to download ffmpeg.exe elsewhere and put it in the same folder as CUETools.
IMHO libALAC compresses better and faster, so i wouldn't bother with ffmpeg.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-03-11 19:03:58
thanks for your quick reply. I'll decide between MP3 Splitter and Pcutmp3 for that, everything else goes to CUETOOLS  Thanks again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-03-12 14:58:50
This is a possible anwser to Post #828 by moikboy:

If Cuetools didn't find the rip due to broken INDEX 00, with an anwser like "INDEX must be in chronological order" it is normal that you may find it after deleting the INDEX 00, it only means that the gaps were only including silence (& not data), so the AR checksum didn't change with or without gaps.

I don't know if it is a known EAC issue but sometimes INDEX 00 are frozen. In this case & if gaps are nothing but silence you can still check if the rip is accurate by deleting gaps (INDEX 00) [Edit: If the rip is in database indeed]. Then your rip might be accurate (scratchless) but you've lost the layout of the CD (gaps). It might be an issue for you, but if you intend to encode to lossy, then it is not really an issue as the layout of gaps will be lost during the lossy encoding anyway.

So, as far as I understund, the fact that you are able to check if the rip is accurate without the gaps doesn't necessary means that there are 2 pressings of the CD, specially if gaps are silence.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: TangoTonyB on 2010-03-14 17:46:36
I've been trying out the repair feature of 2.06 and either I'm missing something or there's a problem.

I have a CD which is in the Accurip database because I get the following report back on Verify:

Code: [Select]
[Verification date: 14/03/2010 05:38:00]
[Disc ID: 00255b92-01a74ec6-d60feb0f]
Track    [ CRC    ] Status
01    [85eba639] (00/02) No matches
02    [3d8e788e] (00/02) No matches
03    [f6d2e85a] (00/02) No matches
04    [a5465742] (00/02) No matches
05    [7d1137ab] (00/02) No matches
06    [aa1a6b26] (00/02) No matches
07    [6eb37571] (00/02) No matches
08    [a66c3f6e] (00/02) No matches
09    [d9806bc2] (00/02) No matches
10    [5c1f1e19] (00/02) No matches
11    [157c07ef] (00/02) No matches
12    [384eed1e] (00/02) No matches
13    [2acda4ae] (00/02) No matches
14    [42c78016] (00/02) No matches
15    [5194d9e5] (00/02) No matches
Offsetted by 667:
01    [fe49618c] (02/02) Accurately ripped
02    [3dffab43] (02/02) Accurately ripped
03    [63e4fc87] (02/02) Accurately ripped
04    [390a10cd] (02/02) Accurately ripped
05    [073bb6f9] (02/02) Partial match
06    [520642f8] (02/02) Accurately ripped
07    [45bd5962] (02/02) Accurately ripped
08    [6318ca19] (02/02) Accurately ripped
09    [b2ac5735] (02/02) Accurately ripped
10    [5fa98045] (02/02) Accurately ripped
11    [f9089b5f] (02/02) Accurately ripped
12    [5369d661] (02/02) Accurately ripped
13    [19af3685] (02/02) Accurately ripped
14    [4e3abeb6] (02/02) Accurately ripped
15    [452c18c2] (02/02) Accurately ripped

Track    [ CRC32  ]    [W/O NULL]    
--    [77F2E0DF]    [405B2512]    
01    [F6763232]    [91C966F6]    
02    [25647865]    [13BC7324]    
03    [E2E1EC6A]    [6842BD0B]    
04    [F19F16C9]    [90A28999]    
05    [60FE7FB3]    [31EE2916]    
06    [30C65F25]    [DB6BE99B]    
07    [403745C5]    [5DBE617E]    
08    [7380A502]    [AC4ADD09]    
09    [06818E43]    [340C6B72]    
10    [45DC4B1D]    [0D80218B]    
11    [3A7EF676]    [E226C4C7]    
12    [F990C45B]    [5349BAED]    
13    [8B59A896]    [A73217EC]    
14    [347EB92A]    [788AF5AB]    
15    [8DD28776]    [E46894AE]


But when I select Repair - I get the error that it's not in the CueTools DB

So I'm assuming either the CueTools DB doesn't contain the same CDs as the Accurip one, or there is a program error, or I have not configured something correctly.
If it's the database, then how do CDs get added to the Cuetools DB??

Thanks,

Tony


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-14 17:58:11
If it's the database, then how do CDs get added to the Cuetools DB??

Two ways currently.
First by CUETools: in verify mode select 'submit' from the combobox under actions list. In this mode only CDs which pass AR verification with confidence > 2 will be added.
Unfortunately your CD has low AR confidence, so it cannot be submitted this way.
Second way is when you rip CD using CUERipper.

Even if it was in database, repairing your rip using an entry that has small confidence number is rarely a good idea, because you can't be sure that the rip in database is really accurate. You will just replace your errors with someone else's.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-03-14 18:20:06
Why >2 and not >=2 ? Is there any real technical difference between AR2 & AR3 ? I mean so far I thought AR2 was enough, so I am a little surprised. I knew AR0 & AR1 weren't trustworthy, but your lack of confidence in AR2 is a little odd, unless I missed something. I mean the only exception I can think of right now is if the supposed error is due to the fact that there are several pressings of the CD & that you're testing a pressing that is not in the database against different, more popular, pressings that are in the database ... but even in this case a higher AR confidency will not help you much. I don't undestand why an AR2 rip wouldn't be "really accurate" except for the fact that if confidency would be higher it would indeed be better. For me an AR2 rip result from an original CD is accurate untill someone prove that the AR database is broken.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-14 19:30:44
You are probably right, and as greynol often points out there's no real difference between various confidence numbers which people choose as a threshold. I had to choose some number, so i more or less rolled the dice. This doesn't make a big difference at this point, because there's little hope to find such rare CDs in the database anyway, but i'll think about it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-03-15 11:04:29
Issue:

I get the familiar "CUE Tools has encountered a problem and need to close" with every 2.x version. Not with latest stable.

- OS: XP MCE
- .NET version: Tried version 2 with update as specified, and also upgraded to 3.5. Same results.



Issue does not disappear with 2.0.6. (Will probably work on another computer with a different XP.)


Another computer, another XP (freshly installed XP, freshly installed .NET 3.5 with SP1):
"Exception has been thrown by the target of an invocation.."

Hm ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-15 18:02:07
Another computer, another XP (freshly installed XP, freshly installed .NET 3.5 with SP1):
"Exception has been thrown by the target of an invocation.."

If it's a plain XP without at least SP2, i'm afraid i'll just declare it as an unsupported OS version.

If it's SP2/SP3, can you please provide more details? Does it crash during application startup or when you press 'Go'? How does it look? Screenshot would be nice.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2010-03-16 21:18:53
just FYI, when I try to use CUERipper, I immediately get "Exception: invalid C2 pointers" when I hit go. Ripping works fine with EAC otherwise. Does this in all modes (burst, secure, paranoid).

Progress is looking good... I'm looking forward to the release version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2010-03-17 14:33:25
I am also having a problem with 2.0.5 & 6. When I select verify, I get a "Exception: Exception has been thrown by the target of an invocation.:External component has thrown an exception" error. If I switch from libFlac to libFlake under the Formats tab/decoder, no problems. No problem with 2.0.4 .

WinXP SP3
Aflon processor
MS Visual 2008
DotNet 3.5 SP1
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-03-17 15:00:11
Another computer, another XP (freshly installed XP, freshly installed .NET 3.5 with SP1):
"Exception has been thrown by the target of an invocation.."

If it's a plain XP without at least SP2, i'm afraid i'll just declare it as an unsupported OS version.

If it's SP2/SP3, can you please provide more details? Does it crash during application startup or when you press 'Go'? How does it look? Screenshot would be nice.


SP3, sorry for being unclear. It is when I press "Go" (having selected Verify) and it appears in the report window below, just like where the usual output would be. (If you still need a screenshot, I could fire up that computer next time I visit it.)


Edit: Think I used libFlac too.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-03-17 17:25:45
What might be the reason for this message?

Code: [Select]
---------------------------
Error
---------------------------
Exception: Unable to initialize the encoder.
---------------------------
OK  
---------------------------


libFLAC, Vista, worked some days ago.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-17 17:58:40
What might be the reason for this message?

One of possible reasons is that output path is invalid. I'll make a special error message for this case. Try choosing libFlake, it'll probably show a more detailed error message. Or it might just work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-03-17 18:00:14
I don't have flake.exe. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-17 18:26:24
Not flake, libFlake. Take a look at the list of flac encoders: there should be libFLAC, libFlake, flake and FlaCuda. libFlake is a builtin encoder based on Flake.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-03-17 18:35:02
Hmm, just found v2.0.6 - there's no libFLAC anymore, it seems.
And it does not accept FLAC files anymore. ("Unsupported audio format.")



edit: NVM, a completely fresh installation seems to work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2010-03-17 21:27:08
Feature request (as I don't get the thing running, it might already be implemented  )

For lots of CDs, CUETools fails to compute the correct AccurateRip ID. According to Spoon, this is not only for CD-Extras with data, but also when a CD fails to start at frame 150.
But dBpoweramp writes the tags "AccurateRipDiscID" (which is really a track ID) and "AccurateRipResult". I might be wrong, but EAC does not?


So:

1) I know that we dBpoweramp users are in minority compared to EAC users, but I would wish for an option to use ID from tags rather than computed. I have nagged Spoon on this too, http://forum.dbpoweramp.com/showthread.php?t=20563 (http://forum.dbpoweramp.com/showthread.php?t=20563)

2) Since you are putting up this database: What about having the database store the information that calculated ID fails to match tag-read ID, whenever applicable? Then next time this CD is checked, and fails check because ID does not match the AccurateRip database, one may look up the CUETools database and find that this CD with calculated ID = X really has ID = Y in the AccurateRip database, and verification may proceed with ID = Y instead, which should produce a hit.

This way, dBpoweramp users will populate the database with information on what ID to really use.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-03-17 21:56:31
Does the CUETools DB even care about this stuff?  I don't see that it should; consolidation is a good thing!  It would be great to consolidate discs with the exact same PCM data but slightly different TOCs (beyond data track and track 01 start point) as well.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-19 15:43:43
just FYI, when I try to use CUERipper, I immediately get "Exception: invalid C2 pointers" when I hit go. Ripping works fine with EAC otherwise. Does this in all modes (burst, secure, paranoid).

What's your CD drive model? Does EAC detect it as capable of returning C2 pointers?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fromsilenceandanything on 2010-03-22 20:01:54
I'm sorry if this has been discussed to death, but I'm getting utterly confused by this pregap mess, so I'll ask here...

I have an image FLAC of an album with a cue and a log with TOC. If I mount the cue and verify the album via foobar2000's AccurateRip verifier, I get 3 confidence. According to the cue there's a 00:00:01 pregap.

Now if I split the album into separate FLAC tracks using CueTools, AccurateRip verifier will not find the album in the database. Is it possible to split the album and still have it accurately ripped WITHOUT the cue? If it is, how?

I've tried with "Gaps appended" and "Gaps appended + HTOA" but it doesn't seem to make a difference. I've also tried adding the 00:00:01 pregap manually in the CueTools settings, to no avail (not sure if there's something else than the mere pregap that needs to be adjusted, though). I have to use a cue to verify it with AccurateRip whether the tracks are separate or not.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-22 21:09:27
I'm sorry, i'm no expert in foobar AccurateRip verifier, i wasn't even contacted by it's author and i have no idea how much of my code does it use.
I guess it just doesn't support pregaps very well, so you'll have to use CUETools & cue sheet to verify this album.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-03-22 22:25:56
just FYI, when I try to use CUERipper, I immediately get "Exception: invalid C2 pointers" when I hit go. Ripping works fine with EAC otherwise. Does this in all modes (burst, secure, paranoid).

What's your CD drive model? Does EAC detect it as capable of returning C2 pointers?

I have the same problem.

CUERipper 2.0.6
XP SP3 with the latest updates from MS, including all .NET updates
The drive is a Samsung SH-W162 (TSSTcorpCD/DVDW SH-W162C TS12 as reported by EAC)

C2 works with EAC. CUERipper 2.0.4a doesn't have this problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fromsilenceandanything on 2010-03-22 23:09:05
I'm sorry, i'm no expert in foobar AccurateRip verifier, i wasn't even contacted by it's author and i have no idea how much of my code does it use.
I guess it just doesn't support pregaps very well, so you'll have to use CUETools & cue sheet to verify this album.
If I verify the album in CueTools by choosing the FLAC files (after splitting the album with CueTools), the program will suggest me to use the log file. All cool, but this way it still won't find the disc in the database. I may also remove the cue and the log so it just checks purely the files, but the disc is still not found. If I choose the cue instead of the FLAC files, I get accurate results.

So all in all, this still leaves me cue dependent. I'd like to fare without the cue, for personal convenience. Possible or not?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-03-23 00:18:23
I'm sorry, i'm no expert in foobar AccurateRip verifier, i wasn't even contacted by it's author and i have no idea how much of my code does it use.
I guess it just doesn't support pregaps very well, so you'll have to use CUETools & cue sheet to verify this album.
If I verify the album in CueTools by choosing the FLAC files (after splitting the album with CueTools), the program will suggest me to use the log file. All cool, but this way it still won't find the disc in the database. I may also remove the cue and the log so it just checks purely the files, but the disc is still not found. If I choose the cue instead of the FLAC files, I get accurate results.

So all in all, this still leaves me cue dependent. I'd like to fare without the cue, for personal convenience. Possible or not?


If I am not mistaken, when using the Cue File, Cuetools will also check for the DISCID comment in the cue file, & will attempt to use this information.
Do a test & check for it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fromsilenceandanything on 2010-03-23 01:03:06
If I am not mistaken, when using the Cue File, Cuetools will also check for the DISCID comment in the cue file, & will attempt to use this information.
Do a test & check for it.
The DISCID is not present in the original cue, but CueTools adds it in the new cue it creates after splitting the image. But, what follows? How can I utilize this ID?

I hope I've been coherent, but I emphase that it doesn't matter whether I check the split files with foo_verifier or CueTools. They both give me the same results with the cue (=accurate) and without (=not found).

I guess it's about the 00:00:01 pregap, but I don't know how to go round it. It's in the beginning of the CD and it's the only pregap on it. I can post the cue here if it helps.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-03-23 21:16:35
I have an idea for a new feature. Hm, I haven't checked if it already works but... here's what I mean:

The drag'n'drop/folder/multi-select browser should support m3u/m3u8 files as a source for batch jobs. Sometimes people might create a list of audio files or cue sheets with a text editor (for example by using 'find in files') or with a batch script and they want to process these files in one go. Then it would be nice to be able to add such a list as a file into CUE Tools.

Another thing: when having multiple items in the drag'n'drop list, switching to multi-select should automagically mark all the previously added items in the browser view. this should also work the other way round: all items that have been selected in the multi-select browser should appear as a list in the drag'n'drop view. It's not an essential feature, but a nice usability detail. Oh, then CUE Tools would need a clear list button, btw.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-03-24 17:32:49
Regarding the CUERipper / C2 problem, a problem report was posted in the old CUERipper thread:

I hope I'm not resurrecting a thread that's too old but this seems like the most appropriate place to report CUERipper issues....

I tried ripping a CD using CUERipper 2.0.6.  My drive model is identified as "TSSTcorp CDDVDW SH-S203B SB03"  CUERipper will get the disc name and track titles correct but when I press "GO", after about 2-3 seconds I get an error pop-up with the following message "Exception: invalid C2 pointers" and the rip stops.  I tried several CD's and all yield the same results.

I'm really excited to try my luck with CTDB for ripping 3 or 4 of my discs that have 1 track damaged.  They are late 1980's releases and I have not been able to find non-remastered replacements at the local used stores. 

Thanks

I quoted it in here in order to keep the discussion in one place. The drive in this report is another very common Samsung model. I think I have the same drive on another PC. I can try it later today.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-03-25 19:21:49
I tried the other PC. The same error message shows up. The drive isn't exactly the same as in the above report, but close. I have the EIDE version. Here's a screenshot of the error message:

(http://i238.photobucket.com/albums/ff132/alexb2k/HA/InvalidC2pointers.jpg)

The OS is Windows 7 32-bit.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-25 23:02:01
Thank you. I'll have to add one of those drives to my shopping list. Here's a slightly different version of CUERipper, i hope this works: http://www.cuetools.net/install/CUETools_2.0.7.rar (http://www.cuetools.net/install/CUETools_2.0.7.rar). This is only a CUERipper update, no changes to CUETools there.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-25 23:14:50
So all in all, this still leaves me cue dependent. I'd like to fare without the cue, for personal convenience. Possible or not?

If you don't want to keep logs & cue, the only way is to keep ACCURATERIPID tag. If you enable AccurateRip when converting with CUETools, and AccurateRip tags are enabled in advanced settings (AccurateRip->Encode and Verify->Write AccurateRip tags), CUETools will create this tag for you.

The problem with this method is that there are many tagging applications out there, which can accidentally destroy unsupported tags such as this. You will also have trouble using CUETools DB if pregap wasn't completely silent.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radio_cascara on 2010-03-26 16:13:11
Hello, let me first tell that I'm not really familiar with cue sheets and I'm total newbie when it comes to their splitting. I carefully read readme file, wiki and 2 of threads, but haven't been able to clarify my dilemma

I have single flac with cue sheet. I split it to separate files using cuetools. After it is done new cue sheet is generated. This new cue sheet is not playable in foobar 0.9.6.9 while original was (Error parsing cuesheet: invalid index list).

I've think I've read there might be problems with foobar and nonstandard cue sheets. So my questions:

1. Can original disc be rebuilt from multiple flac tracks and such newly generated sheet? I think I've tried it and the cue sheet for new image was different than starting original.

2. Is there a way a person that doesn't know cue format well can tell if the splitting went well or not and is new cue sheet borked or not?

3. Can one leave "Gaps appended + HTOA" when original cue sheet has no pregaps and get same result as "Gaps appended", or does one have to know what sort of cue he has.

I guess one that wants to call himself audiophile should know these answers, but I don't  I just want to be split my images but be able to reproduce them if ever needed. Thanks in advance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: krafty on 2010-03-26 19:33:12
Can this program be run on Linux? I have read this is possible with the right libraries, the Mono ones... however, there is no tutorial that will explain how to do this. Actually, it would be nice to have a full port, even limited with FLAC and WAV support, at least. A website for this application is also missing, so I suggest the creation of a sourceforge.net account and hosting this project there. Keep the good work, because I really like this application.

Cheers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2010-03-27 13:34:58
CUETools_2.0.7

thx
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2010-03-27 15:30:29
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-27 17:37:42
Oops, sorry again, forgot one file, had to reupload.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-27 17:49:25
1. Can original disc be rebuilt from multiple flac tracks and such newly generated sheet? I think I've tried it and the cue sheet for new image was different than starting original.

The disc can be rebuilt. At least with CUETools. Track lengths and indexes will remain exactly the same. It's very unfortunate that foobar doesn't understand 'gaps appended' cue sheets, for me this is it's biggest problem, second being incorrect handling of pregaps. However, you can still load those files into foobar using m3u file.

2. Is there a way a person that doesn't know cue format well can tell if the splitting went well or not and is new cue sheet borked or not?

I never heard of any problems with cue's generated by CUETools, this worked perfectly even before i hijacked this project, and as far as i know i never broke this feature. You can easily check this by converting resulting cue sheet back to image format. Wile doing this, tou can select 'Audio output: none', if you want it to be fast and don't want a third copy of audio files.

3. Can one leave "Gaps appended + HTOA" when original cue sheet has no pregaps and get same result as "Gaps appended", or does one have to know what sort of cue he has.

You can always use "Gaps appended + HTOA". If there wasn't any HTOA, it won't appear.

To summarize: if you use default settings, all should be well. You can damage your image only by selecting exotic features, such as gaps handling methods other than default.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-27 17:58:40
Can this program be run on Linux? I have read this is possible with the right libraries, the Mono ones... however, there is no tutorial that will explain how to do this. Actually, it would be nice to have a full port, even limited with FLAC and WAV support, at least. A website for this application is also missing, so I suggest the creation of a sourceforge.net account and hosting this project there. Keep the good work, because I really like this application.

Cheers.

Most versions were successfully tested on Linux. I didn't test the latest few versions (2.0.5-2.0.7), i will do so when i have time. If they work, they should be much more useful for linux users than older versions, which could only support WAV on linux. New versions should also support FLAC and ALAC.

It's easy enough to run CUETools on linux, just install mono (often as easy as 'yum install mono' or 'apt-get install mono'), and run 'mono CUETools.exe'

Website isn't misisng: http://www.cuetools.net/ (http://www.cuetools.net/) It is however incomplete, so feel free to contribute. It uses wiki engine, so you can just register and start editing pages.

There is also a sourceforge.net account, but it only hosts CUETools source files in SVN.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: krafty on 2010-03-27 18:17:03
Thanks for your explanation Gregory...
I think I am missing something though, as I can't run under mono (1.9.5 and 2.0.4a tested)...

Code: [Select]
$ mono CUETools.exe

** (CUETools.exe:2671): WARNING **: The following assembly referenced from /home/krafty/win32/CUETools_2.0.4a_x86/CUETools.exe could not be loaded:
     Assembly:   System.Windows.Forms    (assemblyref_index=0)
     Version:    2.0.0.0
     Public Key: b77a5c561934e089
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/krafty/win32/CUETools_2.0.4a_x86/).


** (CUETools.exe:2671): WARNING **: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
File name: 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-27 18:26:23
I guess this is a problem with your mono installation. The missing .dll (Windows Forms) should be a part of normal mono package.

If you built it from source, try rebuilding and reinstalling it. Check configure options, perhaps you need to specifically enable Windows Forms support.

If you installed it as a package, perhaps there's a separate package for Windows Forms.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: krafty on 2010-03-27 19:38:40
Gregory, excellent!
I have installed:

libmono-winforms1.0-cil
libmono-winforms2.0-cil
libmono-system-runtime1.0-cil
libmono-system-runtime2.0-cil

Now it works... (both only works with WAV)
Tested 1.9.5 and the 2.0.4a.
Were you saying "new" versions the experimental ones?

Many thanks for this help.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2010-03-27 19:59:54
Oops, sorry again, forgot one file, had to reupload.


THX 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-27 20:00:05
Yep, 2.0.6/2.0.7
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: krafty on 2010-03-27 20:07:25
Confirmed, FLAC working with 2.0.6
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-03-28 14:57:31
Dear all, thanks for this great software, BUT,  I'm having a big issue... files converted to ALAC don't play in my iphone! And I have just spent one week converting hundreds of albums with cuetools to find I now have to do it all again

I am converting flac+cue to ALAC using libALAC. Everything works great, files play ok in itunes under mac and windows. BUT, when I sync files to my ipod, each song is presented as being 3 or 4 hours in length, I get a 1sec sound at the start and then no audio.

If I take these cuetools files and transcode them again to ALAC using MAX... they play perfectly in the iphone...

Is there any reason why cuetool's alac encoding is incompatible with ipod/iphone? anyone else had this experience?
I'm using standard options in cuetools... anything I should have selected/unselected?

thanks in advance, your help is appreciated.

cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2010-03-29 16:28:23
I've found a duplicate in the base here (http://db.cuetools.net/?tocid=ozAmTcdW0sVURX.5cj4nd9rtIb4-). As long as the redundancy file is not uploaded twice, there would be no size problem for the base. If duplicates appear that way though, this could render the web interface unreadable/unsearchable in the future.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-31 07:00:39
I've found a duplicate in the base here (http://db.cuetools.net/?tocid=ozAmTcdW0sVURX.5cj4nd9rtIb4-). As long as the redundancy file is not uploaded twice, there would be no size problem for the base. If duplicates appear that way though, this could render the web interface unreadable/unsearchable in the future.

Thank you. This shouldn't happen, i will find out why it did.
Code: [Select]
ctdb=> select DISTINCT tocid from submissions2 s1 where exists(select * FROM submissions2 s2 where (s1.id <> s2.id AND s1.tocid = s2.tocid AND s1.crc32 = s2.crc32 AND s1.trackcount = s2.trackcount));
            tocid
------------------------------
6BsNdDOAjhrnEfNfk0Nj65F30ag-
m.NFbfRVymivB0Gxo2nKCqljoTo-
ozAmTcdW0sVURX.5cj4nd9rtIb4-
(3 rows)

Looks like there's already three of them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-31 07:15:20
I am converting flac+cue to ALAC using libALAC. Everything works great, files play ok in itunes under mac and windows. BUT, when I sync files to my ipod, each song is presented as being 3 or 4 hours in length, I get a 1sec sound at the start and then no audio.


That's very unfortunate. I'm sorry, i don't have an ipod (i prefer cowon), so i cannot fix it right now, not until i borrow one. When i first published this encoder and asked to test resulting files on ipod, there were reports that it works. Encoder didn't change much since then, so there's a possibility that it does work on certain models/firmware versions, so can you please tell which one do you have?

The only option in cuetools that could affect this is a high compression level (9-10), but i doubt it.

UPD: here's three clips encoded with different versions of encoder. Can you please test if any of those work on your ipod?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-03-31 11:27:37
I am converting flac+cue to ALAC using libALAC. Everything works great, files play ok in itunes under mac and windows. BUT, when I sync files to my ipod, each song is presented as being 3 or 4 hours in length, I get a 1sec sound at the start and then no audio.

UPD: here's three clips encoded with different versions of encoder. Can you please test if any of those work on your ipod?

I have an ipod touch latest hardware (3rd g), with latest OS (3.1.3) and I can reproduce the problem described by neovibe: the file length when playing is 16:16, although in the description it accurately says 0:22.

If the files are converted to Apple Lossless with itunes they play correctly. I am enclosing them here in case it will be of help.

I have also tried adding the itunes tags BPM, ITUNESMEDIATYPE, ITUNNORM from the converted files but without luck.
Cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-03-31 11:54:57
Thank you. This should help.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radio_cascara on 2010-03-31 20:13:53
To summarize: if you use default settings, all should be well. You can damage your image only by selecting exotic features, such as gaps handling methods other than default.


Thank you very much for your most useful and detailed explanation. Also for all the time and hard work invested in this project
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Manlord on 2010-04-02 16:18:59
Gregory, thank you so much for this fantastic tool. I have been using it for some time and now I can't imagine how I could live without it.

When I use it to enconde from image to tracks I like to use the automatic tagging, to write the tags from the cue file. But, if you do this using FLAC the tag that contains the number of tracks is written as "TRACKTOTAL" when the deffault name (I think that) is "TOTALTRACKS". ¿Could you please fix this so everything works automatically?

Thank you for your effort.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-04-02 20:24:49
I am converting flac+cue to ALAC using libALAC. Everything works great, files play ok in itunes under mac and windows. BUT, when I sync files to my ipod, each song is presented as being 3 or 4 hours in length, I get a 1sec sound at the start and then no audio.


That's very unfortunate. I'm sorry, i don't have an ipod (i prefer cowon), so i cannot fix it right now, not until i borrow one. When i first published this encoder and asked to test resulting files on ipod, there were reports that it works. Encoder didn't change much since then, so there's a possibility that it does work on certain models/firmware versions, so can you please tell which one do you have?

The only option in cuetools that could affect this is a high compression level (9-10), but i doubt it.

UPD: here's three clips encoded with different versions of encoder. Can you please test if any of those work on your ipod?


Hello and thank you for your reply.

I am using a recent iPhone 3GS 16gb, libALAC encoder compression set to 5 on cuetools.

Would try the files you sent, but in itunes they show as 0:00 (tried in two intals, MAC and PC).

Regarding the files I already converted, I could probalby use MAX or DBPoweramp and transcode them to ALAC (from ALAC) and it would work... but as I'm not sure what went wrong and I'm not planning to convert these files ever again, I think I'm going to do it all over again. First use CUETOOLS to split to FLAC (would prefer WAV but it doesn't support tags) and then DBPoweramp to convert to ALAC.

...unless a solution comes

still think it's a great tool, thanks for your work.

cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jpl73 on 2010-04-02 21:37:28
Thank you. I'll have to add one of those drives to my shopping list. Here's a slightly different version of CUERipper, i hope this works: http://www.cuetools.net/install/CUETools_2.0.7.rar (http://www.cuetools.net/install/CUETools_2.0.7.rar). This is only a CUERipper update, no changes to CUETools there.



Gregory:  Thanks for the update.  I just tried it out and CUE Ripper works great on my Samsung drive now.  I feel like a kid at Christmas.  First I find FlaCUDA, then I find CUETools and now CUERipper.  This is great!!!


Alex B:  Thanks for copying my post over here, to a more lively thread.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: gregory on 2010-04-03 15:20:02
Could a variable be added to the output syntax that would return the selected audio output(flac, ape, etc.)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jaaktmgi on 2010-04-06 08:23:50
Thank you very much, Gregory, for your continuos work on CUETools!

I have one small problem when using v2.0.7 on Windows XP SP3.

Namely, I am splitting a WAV-file (whole CD image) according to cuesheet that is UTF8 encoded (and has also BOM at the beginning of the file).
The libFLAC is selected as encoder. CUETools does fine job and splits the CD image into tracks that have correct UTF8 filenames.
Unfortunately the created NONCOMPLIANT CUESHEET is not UTF8 encoded and has "?" marks instead of Unicode characters.

I can't figure out what I am doing wrong...
The settings look as seen in the attachment.

Many thanks in advance,
Jaak
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: kitzik on 2010-04-06 09:19:44
Is there any way to disable comment writing for embedded album art (now it writes full album art path as a comment)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-04-06 15:33:16
... Gregory:  Thanks for the update.  I just tried it out and CUE Ripper works great on my Samsung drive now.  ...

I can confirm this. I finally had time to test the v.2.0.7. My Samsung drives work now.

In general CUERipper is very nice, but unless I am missing something, it doesn't seem to be able to handle "various artists" albums. I'd like to request a similar system that EAC has.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2010-04-09 19:47:56
Great updates of cuetools, very much appreciated!

Found a small inconvenience: After the log is written, it's not released by cuetools, so a directory containing the last log can't be deleted or moved (without closing cuetools or using unlocker).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: kasiusclay on 2010-04-10 01:08:50
First of all.  Thanks for all the time you have put into this awesome application, now I have it I would feel a little lost without it.  Talk about making life easy.

  A feature that I would like to see is to be able to choose whether or not the album should have 'FLAGS DCP' in the cue. 

  I have been trying to create a batch file to drop my cue into and have it insert the FLAGS DCP on the next line after the TITLE entry, so far unsuccesful.  If some one can help I would be greatly appreciated.

Again, Great work
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-04-10 20:15:17
using unlocker).

Oh, is it really CUE Tools that has the handle on the log file?

For me usually it is always the file editor (UEdit32 to be exact) or in rare cases the Windows Explorer.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2010-04-11 10:27:46
using unlocker).

Oh, is it really CUE Tools that has the handle on the log file?

For me usually it is always the file editor (UEdit32 to be exact) or in rare cases the Windows Explorer.


After some more testing, it's only after a log written when a cd is not found in the AR database (I'm using the "only if found" script.
And only the last one.
But it is  cuetools which has the handle then.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-04-11 13:08:19
After some more testing, it's only after a log written when a cd is not found in the AR database (I'm using the "only if found" script.
And only the last one.
Ah, ok. That explains why I never encountered it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: flacfloc on 2010-04-12 02:26:15
Sorry if it was previously answered, but is there a batch mode? I am planning on verifying lots of albums overnight but I don't know if there is a "queue" option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Steve Forte Rio on 2010-04-14 18:31:15
Where I can find the list of changes from 2.0.4a to 2.0.6?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2010-04-14 18:36:34
here (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=690913)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2010-04-16 21:51:34
Sorry if it was previously answered, but is there a batch mode? I am planning on verifying lots of albums overnight but I don't know if there is a "queue" option.


I use drag 'n drop and it's possible to drop many directories (at the same time, not while checking other directories), also subdirs are checked.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-20 02:38:31
Hi,

Apologies for posting this info in a different thread, I am hoping you guys can help me out.

My story:  Three years ago, I ripped my entire CD collection to FLAC (tracks, no CUE) via EAC.  I had always noticed tiny gaps in my seamless albums, but thought it was normal.  I was finally made aware this is not, and virtually all of my rips have the dreaded 4608 samples of silence appended to each track.  Sometime in 2008, I must have installed a different version of EAC, because my recent rips are fine.  I am told I can fix this with CUETools.

My songs are structured simply, like this:

\\NAS\Music\Artist\Album\song1.flac

I downloaded and installed CUETools for my Win7 x64 machine.  My first problem seems to be a window error, as I cannot expand the window as seen on my screen grab.  I tried both 2.0.4a and 2.0.6.

I need some help with configuration, as I want to keep my folders and tags the exact same, I just want me destination to be my D: drive.  I seem to be able to do all of this, except set my destination drive to D:.  The program keeps wanting to put in on my C:Music folder, but that will not hold all of my music, it is a small boot drive.  I also want to be able to run a batch file of all my folders/flacs, even though 10% of my songs don't have the 4608 samples of silence.  I hoping the program will just re-encode as-is.

Finally, can you tell me what my Pregap, Data Track, Offset and Gaps handling settings should be?  I don't want anything changed except chopping off the 4608 samples of silence where applicable.  Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-20 10:41:15
My first problem seems to be a window error

The only window error i see on this screenshot is that offset field is not visible. This is a known issue caused by large fonts setting.

I need some help with configuration, as I want to keep my folders and tags the exact same, I just want me destination to be my D: drive.  I seem to be able to do all of this, except set my destination drive to D:.  The program keeps wanting to put in on my C:Music folder, but that will not hold all of my music, it is a small boot drive.

Try this template:
D:\$directory(%path%,-10,-2)\%filename%.cue
This should keep the folder structure intact.

You can also change your 'My Music' folder location by selecting the desired folder in the folder browser, right click -> "Set as My Music folder". This will affect not only default destination for CUETools, but Windows Media player and other software, so be careful. When i set this folder to my drive with 1TB of music, i had to turn off media player service which was torturing HDD trying to index all those files.

I also want to be able to run a batch file of all my folders/flacs, even though 10% of my songs don't have the 4608 samples of silence.  I hoping the program will just re-encode as-is.

Yes. Just enter the folder path (\\NAS-01-1D-A5\Music\) in the input field, and it should process all the contents of this folder.

Finally, can you tell me what my Pregap, Data Track, Offset and Gaps handling settings should be?  I don't want anything changed except chopping off the 4608 samples of silence where applicable.  Thanks!

Pregap, Data Track, Offset should normally be zero. All advanced settings should be at their default values. Gaps handling for example should be Gaps appended + HTOA.

There aren't many settings relevant to your task that you should change.
You should set Mode to Tracks, if you don't want whole-album single-file images.
You should uncheck three checkboxes with icons (musicbrainz, freedb and accuraterip), because you probably don't need/want to access those databases.
Under 'Action', instead of 'fix offset' select 'default'. 'fix offset' has nothing to do with your task.

You might also want to check 'Keep original filenames' in Advanced settings (first tab, first option on the right side)

Good luck!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-20 11:27:48
I am converting flac+cue to ALAC using libALAC. Everything works great, files play ok in itunes under mac and windows. BUT, when I sync files to my ipod, each song is presented as being 3 or 4 hours in length, I get a 1sec sound at the start and then no audio.


Please, can you check if this file plays ok on ipod: [attachment=5852:sylvian_enc8.m4a]
It should be almost identical to the files produced by iTunes, so i hope it works.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-20 12:13:01
Gregory, thank you so much!

I'll be trying your recommendations later today.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-04-20 12:15:04
I am converting flac+cue to ALAC using libALAC. Everything works great, files play ok in itunes under mac and windows. BUT, when I sync files to my ipod, each song is presented as being 3 or 4 hours in length, I get a 1sec sound at the start and then no audio.


Please, can you check if this file plays ok on ipod: XXX
It should be almost identical to the files produced by iTunes, so i hope it works.
Tested on ipod touch (3rd g), OS (3.1.3) and it works 
Thank you very much for supporting this without having (or wanting) the corresponding hardware.
Cheers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2010-04-20 13:41:57
hi - quick question - is there a way to manually adjust offsets without referencing accuraterip? i have a few cds where i know the offset is wrong and how much it needs adjusting but the cds are not in the accuraterip database. am new to the program but i havent been able to find a way to force an offset adjustment as yet. is there one?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-20 13:54:45
Yes. Don't select scripts such as 'fix offset' - leave it to default. Just enter the offset adjustment into 'Offset' field, then encode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2010-04-20 17:00:36
Yes. Don't select scripts such as 'fix offset' - leave it to default. Just enter the offset adjustment into 'Offset' field, then encode.


wonderful. thanks for the tip. had a feeling there was probably a way to do it
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-21 00:30:34
Gordon,

All of your recommendations seem to have worked very well.

The only thing I noticed, is that a CUE sheet is also created for each album.  I don't need a CUE sheet.  What setting would cause this?  I have followed your instructions to the letter.  Mode = Tracks.

Thanks again for your help, I could have never figured this out without your assistance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-21 01:42:42
^^ Oops, sorry meant to type Gregory.

Actually, I suppose it is OK to have a CUE in each album folder.  If I need to burn from CD going forward, the CUE sheet will be right there and I can use EAC for a quick burn.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-21 03:09:39
I see now this is a dummy CUE sheet.  Please let me know if there is an option to disable its creation.

Thanks again,
Sam
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-21 16:00:43
Hello again,

I have one more question, in addition to my dummy CUE sheet query: I have some native MP3 files (downloads codes from LPs, Neil Young Blu-ray MP3 downloads, etc).  Since I'm running all my music folders through CUETools as we speak, I suppose it's going to re-encode those MP3s to FLAC.  Is this bad in any way?  I'd prefer to keep them as MP3 (easier transfer to other devices).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-22 02:36:56
No, it will not transcode mp3 to flac. It only works with lossless audio. It will not even copy mp3s to the destination folder.
You should not assume that everything in your source folder will be copied/converted to the destination.
It will not copy lossy files, unknown formats, artwork and such, so you shouldn't just delete the source folder after conversion, or you might loose some files.
As for dummy CUE sheets, if you really don't want them, you can find and remove all of them using windows explorer,
just search for all .cue files in the destination folder (or all .cue files containing works "CUETools dummy"), and remove them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2010-04-22 07:21:52
Any way to make CueTools not require the EAC log file and cue sheet to have the same filename in order to add the info about whether the CRCs match the ones in the log? EAC creates logfiles named "artist - album.log" and cue sheets named "album.log" with no way to change it, and the bulk of my old rips are already in this format. If only one log and cue exist in any given folder, CueTools should assume they belong to the CD contained in that folder, no?

Also, would it be possible to add "Yes, ALWAYS!" to the "One or more output file already exists" dialog? There are times when I'm verifying a batch of discs that may already have accurip logs in the folder that can be safely overwritten.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-04-22 10:52:09
I am converting flac+cue to ALAC using libALAC. Everything works great, files play ok in itunes under mac and windows. BUT, when I sync files to my ipod, each song is presented as being 3 or 4 hours in length, I get a 1sec sound at the start and then no audio.


Please, can you check if this file plays ok on ipod: [attachment=5852:sylvian_enc8.m4a]
It should be almost identical to the files produced by iTunes, so i hope it works.


Sorry for the late reply, will check on iPhone 3Gs later tonight. Thank you for taking the time to do this, would save me a lot of trouble. As I said, DBPoweramp's ALAC encoding works fine (don't know if it's the same encoder you're using...)

oh and count me in for the request someone made on adding "Yes, ALWAYS!" to the "One or more output file already exists" dialog. I keep getting this and can't find any file being replaced... actually, after I tell "yes, overwrite", I check the folder and checking the "date modified" I can't find any file that has been overwritten (modifed).

Again, thank you for all of this, it is very very usefull.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-23 22:31:07
Hello:

I keep my music in Apple Lossless format, to play in iTunes. Most of these were converted from FLAC or WAV, either by dBpoweramp or by CueTools. I also retain .cue sheets from the original rips.

Usually if I place the original .cue sheet into the folder containing the ALAC files, I can use CueTools verify to check rip accuracy. However, it does not work on some albums and CueTools reports: Decoding failed.

I wondered if perhaps CueTools had problems with the files converted by dBpoweramp. So, today I used CueTools to convert a single range rip FLAC to individual ALAC tracks and new .cue sheet for the individual files. I then put that new .cue sheet into CueTools and ran verify. I received that error: Decoding failed.

What does this mean? Why can CueTools verify some ALAC files, but not decode others?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-24 06:05:04
That's a bug in current version, will be fixed soon.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-24 13:30:01
That's a bug in current version, will be fixed soon.

Does the bug affect the conversion/encoding, or just the decoding/verify?
In other words, are the files I already converted using CueTools okay? Once the bug is fixed, will CueTools be able to verify all the Apple Lossless files that I have already converted, and not fail on some of them?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-24 14:30:29
Once the bug is fixed, will CueTools be able to verify all the Apple Lossless files that I have already converted, and not fail on some of them?

Yes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-24 16:25:21
Thank you. Any estimate on when that version will be released.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-24 18:50:48
Does this count as an estimate?  http://www.cuetools.net/install/CUETools_2.0.8.rar (http://www.cuetools.net/install/CUETools_2.0.8.rar)

Bug-fix release 2.0.8 changelog:
1) Fixed bug in libALAC decoder which sometimes caused it to abort with error messages like "invalid frame"
2) Fixed bug in libALAC encoder which produced files non-compatible with iPod - thanks to prefab and neovibe for testing
3) Fixed bug in libFlake encoder which caused data corruption when using variable block size (compression level 11) - thanks to Ipsum for bringing this to my attention
4) Fixed bug in peak level measurement in verification log: it now produces exactly the same values as EAC
5) AR verification speedup for albums with many short tracks
6) CTDB verification speedup
7) mp3 encoding is now a bit faster when using lame_enc.dll instead of lame.exe; Download lame_enc.dll and put it into corresponding "plugins (Win32)"/"plugins (x64)" folder
8) Support for external encoders which don't support pipes (such as iTunesEncode): if you use %I in encoder parameters, temporary file is created
9) If log file name doesn't match cue file name, but it contains the same TOC as a cue sheet, it is used automatically
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-04-24 18:56:45
Testing. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-24 19:15:31
Hello Gregory,

Your tips about removing the Dummy CUE file have worked, and CUETools successfully zapped all those nasty 4608 samples of silence where applicable.

The only problem that has resulted, is that all my track number tags have disappeared!  All of the rest of the tag info remained.  Could this be related to the dummy CUE files I deleted?

Losing 2000 albums worth of track tag info is very frustrating.  I do have a back-up from last month, but of course it would have to be run through CUETools as the back up still has the 4608 samples problem.

I use MP3tag for tagging.  I think there is some kind of script that will allow for taking the first two characters of my track names and convert them into tagged track numbers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-24 19:21:48
The only problem that has resulted, is that all my track number tags have disappeared!

Wierd. They shouldn't have. Just tested it, and foobar2000 sees the track numbers in converted files normally, using TRACKNUMBER tag. Maybe you use a different tag?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-24 19:57:25
The only problem that has resulted, is that all my track number tags have disappeared!

Wierd. They shouldn't have. Just tested it, and foobar2000 sees the track numbers in converted files normally, using TRACKNUMBER tag. Maybe you use a different tag?


Yeah, I'm not sure what happened.  I use the "Track" tag in MP3tag, I don't see any other fields to store a tag in.  The stuff that CUETools could not process, like my MP3s with ID3V2.3 tags and 24/96 FLACs kept their tags intact.

All other tag info is fine.  I wonder if I selected something incorrectly in CUETools?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-24 20:17:28
Well, you could have accidentally unchecked 'Write basic tags from CUE data' in Advanced Settings->Tagging...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2010-04-25 14:55:50
Bug-fix release 2.0.8 changelog

Hi, Gregory.

Can't make this version work. Every time I try to verify (in normal mode) CUEtools 2.0.8 gives me a message
"Exception: Unable to find an entry point named 'hdcd_decoder_process_buffer_interleaved' in DLL 'hdcd.dll'."
I have this message on general ape and flac files (they are images of general CDs, not HDCD).

Version 2.0.4a works as expected.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-04-25 15:11:03
Well, you could have accidentally unchecked 'Write basic tags from CUE data' in Advanced Settings->Tagging...


Yes, that was my problem/error.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 16:26:59
Can't make this version work. Every time I try to verify (in normal mode) CUEtools 2.0.8 gives me a message
"Exception: Unable to find an entry point named 'hdcd_decoder_process_buffer_interleaved' in DLL 'hdcd.dll'."

Oops. Try removing plugins\CUETools.Codecs.HDCD.dll. I think i put it there by mistake.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2010-04-25 16:49:27
CUERipper 2.0.8
it is possible?
output-> filename: "track number" - "track title"

at present -> "track number". "track title"

THX 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 16:53:51
Possible, but difficult.

Open <user folder>\AppData\Roaming\CUERipper\settings.txt

Find the following line:

TrackFilenameFormat=%tracknumber%. %title%

and change it to

TrackFilenameFormat=%tracknumber% - %title%
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2010-04-25 17:01:20
THX 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-25 17:35:55
Oops. Try removing plugins\CUETools.Codecs.HDCD.dll. I think i put it there by mistake.

Should we move that file to some other directory, or just delete it? Or, will you soon issue a revised version without the error?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 18:42:22
I already updated the archive, but there's no need to download it again. Just delete this file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-25 19:06:28
I already updated the archive, but there's no need to download it again. Just delete this file.

I had not yet downloaded your latest, so I will do that now.
Is http://www.cuetools.net/doku.php/cuetools:download (http://www.cuetools.net/doku.php/cuetools:download) now the place wheere all updates will appear?

Thanks for all you do!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 19:11:28
I upload updates here and there simultaneously.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-25 20:17:32
Hello:

I downloaded 2.0.8.  For an album that was converted to Apple Lossless m4a files, I put the .cue sheet into CueTools and ran verify. I received that error again: Decoding failed.

It's the same as with 2.0.4. Verify works when used on some Apple Lossless m4a files, but reports that error on others. All were converted, from FLAC or WAV or APE, to Apple Lossless using either CueTools or dBpoweramp.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 20:55:53
Then it's a different bug. I need an example of such file. Do such files play correctly in foobar2000?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-25 21:01:38
Then it's a different bug. I need an example of such file. Do such files play correctly in foobar2000?

I don't know. I do not have foobar2000 installed. I play Apple Lossless files in iTunes 9.1.0.79.

What do I need to do to help you identify this bug? Some Apple Lossless files verify no problem in CueTools, but some deliver that error. All the files play no problem in iTunes, and all were converted to Apple Lossless using either either CueTools or dBpoweramp.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 21:08:48
It would be great if you could upload one of such files somewhere and email me a link (gchudov at gmail dot com). If one of those tracks which produce an error is less than 15mb, you could just send it to me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2010-04-25 21:14:04
Oops. Try removing plugins\CUETools.Codecs.HDCD.dll. I think i put it there by mistake.

Thanks, now it works
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-25 21:35:38
It would be great if you could upload one of such files somewhere and email me a link (gchudov at gmail dot com). If one of those tracks which produce an error is less than 15mb, you could just send it to me.

I found one less than 15 MB. Where do I send it to you?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 21:36:14
gchudov at gmail dot com  Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-04-25 21:36:29
I just tried CUERipper v2.0.8.

It still does not have an option for naming the individual track artists if the CD happens to be a various artists CD.

Here's a cue sheet by CUERipper:
Code: [Select]
REM ACCURATERIPID 0027e7e0-01c523c1-db11e10f
REM DISCID DB11E10F
REM COMMENT "CUERipper v2.0.8 Copyright © 2008-10 Gregory S. Chudov"
REM DATE 2003
REM GENRE "Newage"
PERFORMER "Mixed by Lucien Foort"
TITLE "Slice! Cd01"
FILE "01. Spincycle _ Drug Games.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Spincycle / Drug Games"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "02. Dj On _ Super Sexy Girl.flac" WAVE
  TRACK 02 AUDIO
    TITLE "Dj On / Super Sexy Girl"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "03. Mazi _ Interplay.flac" WAVE
  TRACK 03 AUDIO
    TITLE "Mazi / Interplay"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "04. Timo Mass feat. Kelis _ Help Me (Locodice Dub).flac" WAVE
  TRACK 04 AUDIO
    TITLE "Timo Mass feat. Kelis / Help Me (Locodice Dub)"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "05. Mickey Blue Eyes _ Keep Me Safe.flac" WAVE
  TRACK 05 AUDIO
    TITLE "Mickey Blue Eyes / Keep Me Safe"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "06. Jef Dam _ Soundtrack (Apollo Kids remix).flac" WAVE
  TRACK 06 AUDIO
    TITLE "Jef Dam / Soundtrack (Apollo Kids remix)"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "07. Elijah _ Deep Soul Music.flac" WAVE
  TRACK 07 AUDIO
    TITLE "Elijah / Deep Soul Music"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "08. Funk Function _ Old Skool House Musik.flac" WAVE
  TRACK 08 AUDIO
    TITLE "Funk Function / Old Skool House Musik"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "09. Silver City _ 1969.flac" WAVE
  TRACK 09 AUDIO
    TITLE "Silver City / 1969"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "10. O. C. B. _ Synchronicity.flac" WAVE
  TRACK 10 AUDIO
    TITLE "O. C. B. / Synchronicity"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "11. Briggs & Lievense _ Breakdown.flac" WAVE
  TRACK 11 AUDIO
    TITLE "Briggs & Lievense / Breakdown"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "12. Neruda _ Alliance (Club mix).flac" WAVE
  TRACK 12 AUDIO
    TITLE "Neruda / Alliance (Club mix)"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "13. Moguai _ U Know Y (Starecase remix).flac" WAVE
  TRACK 13 AUDIO
    TITLE "Moguai / U Know Y (Starecase remix)"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "14. Ian Ossia & Marc Mitchell _ 4 Day Haze (We Like The Music).flac" WAVE
  TRACK 14 AUDIO
    TITLE "Ian Ossia & Marc Mitchell / 4 Day Haze (We Like The Music)"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
FILE "15. Silk _ U Spin Me.flac" WAVE
  TRACK 15 AUDIO
    TITLE "Silk / U Spin Me"
    PERFORMER "Mixed by Lucien Foort"
    INDEX 01 00:00:00
And here by EAC:
Code: [Select]
REM GENRE Newage
REM DATE 2003
REM DISCID DB11E10F
REM COMMENT "ExactAudioCopy v0.99pb5"
PERFORMER "Various"
TITLE "Slice! Cd01"
FILE "Various - Slice! Cd01\Spincycle - 01 - Drug Games.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Drug Games"
    PERFORMER "Spincycle"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Dj On - 02 - Super Sexy Girl.wav" WAVE
  TRACK 02 AUDIO
    TITLE "Super Sexy Girl"
    PERFORMER "Dj On"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Mazi - 03 - Interplay.wav" WAVE
  TRACK 03 AUDIO
    TITLE "Interplay"
    PERFORMER "Mazi"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Timo Mass feat. Kelis - 04 - Help Me (Locodice Dub).wav" WAVE
  TRACK 04 AUDIO
    TITLE "Help Me (Locodice Dub)"
    PERFORMER "Timo Mass feat. Kelis"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Mickey Blue Eyes - 05 - Keep Me Safe.wav" WAVE
  TRACK 05 AUDIO
    TITLE "Keep Me Safe"
    PERFORMER "Mickey Blue Eyes"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Jef Dam - 06 - Soundtrack (Apollo Kids remix).wav" WAVE
  TRACK 06 AUDIO
    TITLE "Soundtrack (Apollo Kids remix)"
    PERFORMER "Jef Dam"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Elijah - 07 - Deep Soul Music.wav" WAVE
  TRACK 07 AUDIO
    TITLE "Deep Soul Music"
    PERFORMER "Elijah"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Funk Function - 08 - Old Skool House Musik.wav" WAVE
  TRACK 08 AUDIO
    TITLE "Old Skool House Musik"
    PERFORMER "Funk Function"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Silver City - 09 - 1969.wav" WAVE
  TRACK 09 AUDIO
    TITLE "1969"
    PERFORMER "Silver City"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\O. C. B. - 10 - Synchronicity.wav" WAVE
  TRACK 10 AUDIO
    TITLE "Synchronicity"
    PERFORMER "O. C. B."
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Briggs & Lievense - 11 - Breakdown.wav" WAVE
  TRACK 11 AUDIO
    TITLE "Breakdown"
    PERFORMER "Briggs & Lievense"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Neruda - 12 - Alliance (Club mix).wav" WAVE
  TRACK 12 AUDIO
    TITLE "Alliance (Club mix)"
    PERFORMER "Neruda"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Moguai - 13 - U Know Y (Starecase remix).wav" WAVE
  TRACK 13 AUDIO
    TITLE "U Know Y (Starecase remix)"
    PERFORMER "Moguai"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Ian Ossia & Marc Mitchell - 14 - 4 Day Haze (We Like The Music).wav" WAVE
  TRACK 14 AUDIO
    TITLE "4 Day Haze (We Like The Music)"
    PERFORMER "Ian Ossia & Marc Mitchell"
    INDEX 01 00:00:00
FILE "Various - Slice! Cd01\Silk - 15 - U Spin Me.wav" WAVE
  TRACK 15 AUDIO
    TITLE "U Spin Me"
    PERFORMER "Silk"
    INDEX 01 00:00:00
In both cases all metadata is directly from freedb (I didn't edit it).

Here are a couple of screenshots:

CUERipper's UI - no option for parsing the individual track artists:
(http://i238.photobucket.com/albums/ff132/alexb2k/HA/cueripper208ui.png)

EAC's UI - a tickbox for various artists albums:
(http://i238.photobucket.com/albums/ff132/alexb2k/HA/EAC_various.png)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-25 21:41:06
I see.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-25 22:14:44
I e-mailed the file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-04-25 22:27:01
Some additional notes:

Actually, even EAC doesn't handle various artists albums optimally. When the "Various Artists" option is ticked it changes the album artist's name to "Various". Ideally it should allow to use a global album artist name.

CUERipper could do this better. It could also automatically write the "Album Artist" file tags when the "tracks" ripping mode is enabled.

As a side note, apparently EAC stupidly adds the folder path to the filenames in the CUE sheet when its filename rule is set to create folders. If the cue sheet is saved in the audio files' folder the path will be incorrect. Fortunately CUETools can fix that easily. CUERipper does this correctly.

After ripping is finished CUERipper shows this:

(http://i238.photobucket.com/albums/ff132/alexb2k/HA/cueripper_confidence.png)

"confidence 3" is obviously the number from AR db (two) + one additional from my first rip with CUERipper (after my second rip of the same CD that number increased to four), but what does "8400 has been confirmed" mean?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-04-25 23:43:13
As a side note, apparently EAC stupidly adds the folder path to the filenames in the CUE sheet when its filename rule is set to create folders.
While I like to keep CUEs in the same folders as the files, I wouldn't condemn the idea that cues can be stored at the root of a folder structure as stupid.  That said, there is certainly room for improvement; such as simply presenting users with sensible options.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-26 09:40:21
I e-mailed the file.


Thank you. I think i fixed it. Try the updated http://www.cuetools.net/install/CUETools_2.0.8.rar (http://www.cuetools.net/install/CUETools_2.0.8.rar)
I wonder what software created such a file. It had a slight error in it's mpeg boxes, which shouldn't affect anything so i just ignore such errors now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-26 09:56:54
"confidence 3" is obviously the number from AR db (two) + one additional from my first rip with CUERipper (after my second rip of the same CD that number increased to four), but what does "8400 has been confirmed" mean?

This is a message from CUETools database, that entry 8400 has been confirmed, i.e. it's confidence number increased by 1.
I know it's not very user friendly, but didn't decide yet what to do about it. Either show the long CTDB id instead of entry number, or get rid of this technobabble completely.
By the way, i tried to add some support for Various Artists.
In updated CUERipper 2.0.8 when you right-click on a freedb release, you can choose 'Various Artists' from the menu and it will try to parse it as a Various Artists album.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: onkl on 2010-04-26 12:10:14
Is it possible to set CUETools to use id3v2 tags only? Currently it adds id3v1, v2 and APE to the mp3 files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-04-26 12:21:36
Hi there, did try your sample file and ir works on the iphone 3gs, will try again with the updated cuetools. thanks again!

PS: will be trying to get pcutmp3 to work with cuetools as an external encoder (for lossless mp3 splitting)... is anyone using this with cuetools also?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-26 12:23:17
I don't think it's possible.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-04-26 12:48:35
I don't think it's possible.


Just tried and it's not working indeed...
Usually I use a batch file with the following:

Quote
java -jar pcutmp3_098b.jar --cue %1 --dir "%~dp1
pause
exit


... and then just drag the cue file onto the batch file.

using the command line the parameters are

Quote
--cue <cue-filename>.cue


do you think you can help? this would be the icing on the cake because pcut has no batch processing and through cuetools this would be possible.
also, perhaps this could be somehow included in cuetools because although this is for mp3... it IS a lossless 'encoder' (no encoding actually, I know) and it's a shame one has to recompress mp3 to split...

thanks again, cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-04-26 14:22:31
... By the way, i tried to add some support for Various Artists.
In updated CUERipper 2.0.8 when you right-click on a freedb release, you can choose 'Various Artists' from the menu and it will try to parse it as a Various Artists album.

Thanks. I ripped some additional "Various Artists" discs with the updated v.2.0.8. My findings:

- data is present in freedb:
"Various Artists" can now be set. It is difficult to go back to the Artist / Track view for checking and possibly editing the entries (the view can be reset by ejecting and reinserting the disc or by switching between the drives if you have more than one drive). The Album Artist tag is not added to the track files.

- data is present in MusicBrainz:
Works as before. The Album Artist tag is added to the track files. However, there is no way to see or edit the track artists' names.

- data is not present in the online DBs:
There is now way to type the correct tags if the album has multiple track artists.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-26 14:28:21
Thank you. I think i fixed it. Try the updated http://www.cuetools.net/install/CUETools_2.0.8.rar (http://www.cuetools.net/install/CUETools_2.0.8.rar)

Yes, that seems to work. Thanks!

I wonder what software created such a file. It had a slight error in it's mpeg boxes, which shouldn't affect anything so i just ignore such errors now.

It was either CueTools or dBpoweramp. Those are the only tools I use to convert to Apple Lossless. If it helps, I could do some new conversions, and tell you which ones used CueTools and which ones used dBpoweramp, so you can see the differences if any.


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-04-26 14:43:53
... It was either CueTools or dBpoweramp. Those are the only tools I use to convert to Apple Lossless. If it helps, I could do some new conversions, and tell you which ones used CueTools and which ones used dBpoweramp, so you can see the differences if any.

I wonder if your problem files are encoded with an old version of dBpa's ALAC encoder. Here is a quote from my old reply at the J. River forum (http://yabb.jriver.com/interact/index.php?...27262#msg327262 (http://yabb.jriver.com/interact/index.php?topic=47737.msg327262#msg327262)):

Quote
I was puzzled by the fact that sometimes ALAC decoding through DS works fine and sometimes not.

After running some tests with various ALAC files I found out that an old version of dBpoweramp's ALAC codec creates different tags than the latest version or iTunes. The old version writes tags to the end of the files and the latest version of the dBpa codec and the current iTunes build write them in the beginning of the files. Possibly there are other differences too.

Apparently the DC-Bass Source filter cannot decode files that are created with the old version of the dBpoweramp codec. On the other hand, all files that were created with the latest version of the dBpa codec or iTunes decoded without problems with various DS players. I verified this with MC, WMP, Zoom Player and Media Player Classic.

Possible solutions (these all work for me, but I don't know if you are experiencing the same problem):

- Use the latest version of dBpa's m4a codec or iTunes for encoding the files.
- Fix the old files by using dBpa's "m4a Optimize" tool (it's included in the m4a Utilities codec)
- Fix the old files by using Mp3tag's "Optimize m4a" feature (select the files > right-click > Optimize m4a). Mp3tag is available here: http://www.mp3tag.de/en/ (http://www.mp3tag.de/en/)


EDIT: fixed the link
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-26 14:46:15
It must have been dbPowerAmp then.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-04-26 15:15:58
I wonder if your problem files are encoded with an old version of dBpa's ALAC encoder.

No, not very old. It's version 13.3.

Added: some could have been converted with an earlier version, but even that would not have been very old. It would have been the then-current version last fall, as I think that was when I first began using dbPowerAmp.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-04-27 12:03:33
No, not very old. It's version 13.3.

Added: some could have been converted with an earlier version, but even that would not have been very old. It would have been the then-current version last fall, as I think that was when I first began using dbPowerAmp.

In general, the dBpa codecs are developed separately from the main application. The current "m4a codec" is Release 9. However, the old version I am referring is much older than "last fall" (my quote is from the year 2008), so probably your issue is different (also I don't know if the decoder in CUETools would have the same problem with "old dBpa ALAC" files).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-04-27 21:57:04
I have a question regarding the filename correction in the cue sheet of multi-volume releases. How does CUE Tools do that?

I mean, why doesn't it use the tracks of CD 1 for the cue sheet of CD 2?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-28 08:08:08
It groups files by DISCNUMBER or ALBUM tag. It chooses the group which has the right number of tracks, but fails if two discs have the same number of tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-04-28 13:22:10
Thanks for the new version, specially thks for refocusing on Cuetools after playing with flacuda & libFlake which are not as important to me (I don't use them & IMHO Nvidia is dying).

I like the displaying of the decoding speed, hopefully it will make people realize why flac -4 is great
Also I was happy to fix my first bad rip with the CTDB database
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sonofdbn on 2010-04-28 16:53:38
I tried using CueRipper for the first time (under Windows 7) and when I clicked on Go it started the "Detecting drive features..." part with a green bar at the bottom right, but after a short while there was an error message box. The box was titled "Exception" and the message said:
==============================
Exception: failed to autodetect read command
BEh, 12h, , 16 blocks at a time: ILLEGAL MODE FOR THIS TRACK
(1029.6018ms)
==============================
The last two lines are repeated 5 more times with different hex numbers in place of 12h.

This might look like a drive or CD problem, but I had just ripped the same CD with the same drive using dBpoweramp (and Accuraterip confirmed the rip was OK). So I'm wondering where this error might have come from or if it can be fixed somehow.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-04-28 18:24:47
I am wondering if it's normal to have a rip that is not accurate with a confidence 8 against AR database but accurate with confidence of 6 against the CTDB database ? (Sorry if it's a dumb question the CTDB is new to me ... maybe it has to do with the different strength of checksums or something like that afterall, I dunno)

Code: [Select]
[Verification date: 28/04/2010 17:39:43]
[AccurateRip ID: 000fd7dd-00722687-700a2d09] found.
[CTDB TOCID: AniLFC63ug3HyUZxQ1DzcQ0VzTk-] found.
[ CTDBID ] Status
[e581014a] (6/6) Accurately ripped
Track [ CRC ] Status
 01 [8014e620] (09/09) Accurately ripped
 02 [20f57892] (09/09) Accurately ripped
 03 [b0c6bdd5] (09/09) Accurately ripped
 04 [84196078] (09/09) Accurately ripped
 05 [445d8bbc] (09/09) Accurately ripped
 06 [81485ad9] (09/09) Accurately ripped
 07 [903ad830] (09/09) Accurately ripped
 08 [0681f962] (09/09) Accurately ripped
 09 [1245a213] (08/08) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [0C27D7B0] [7AAC01AB]  
 01  100,0 [93437FAD] [D3D30B3F]  
 02  100,0 [A639BAAB] [E0A0530A]  
 03  100,0 [CC764F44] [79B5834C]  
 04  100,0 [5E3F117F] [8F5D117E]  
 05  100,0 [AC4F224D] [FA59489B]  
 06  100,0 [EBB0CB9A] [B31A84D6]  
 07  100,0 [266BD157] [34138324]  
 08  100,0 [AE18C50A] [111E8DA2]  
 09  100,0 [9D767443] [B12C017E]

Edit:
Also, I don't really understand the difference between CTDB TOCID and CTDBID, I understand CTDB TOCID is a sum that use the TOC to identify the CD but I thought CTDBID was the whole checksum of the CD ... so I don't understand the name CTDBID, is it a checksum or an ID ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-04-28 18:43:00
Exception: failed to autodetect read command

That means that your CD drive model is not supported by CUERipper at this time  What is your CD drive model?

I am wondering if it's normal to have a rip that is not accurate with a confidence 8 against AR database but accurate with confidence of 6 against the CTDB database ?

I'm fairly certain that your rip contains errors only in the last few sectors. AccurateRip ignores last 5 sectors, CTDB - last 10 sectors.

I don't understand the name CTDBID, is it a checksum or an ID ?

It's both. It's a CRC32 checksum of the whole CD except for a few sectors ignored due to offsets, and together with tocid it is used as an id of the database entry that corresponds to this CD's contents.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-04-28 19:03:00
I'm fairly certain that your rip contains errors only in the last few sectors. AccurateRip ignores last 5 sectors, CTDB - last 10 sectors.

EAC had a bug that could have easily caused the discrepancy.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-04-28 20:43:25
Thks for the answers,

As I discussed with Greynol the other day, I already find 5 Frames a little too big for AR (4 is already perfect IMHO), 10 frames for CTDB seems increadibly huge to my understanding ... it would have been nice ... (& natural) if AR & CTDB would have both used the same numbers ... I don't know if there is a technical explanation behind this difference but it would have been easier for everybody to do just like the AR database IMHO.

There is another strange behavior that is annoying me even if it might be normal. CTDB reported to me that two of my rips were enhanced CD when the old way of detecting enhanced CD (without log) doesn't detect them as enhanced CD. I tried to re-check with the datatrack length that CTDB is giving me, twice it didn't match against the CTDB (It matched once against the AR database after fixing the datatrack length while it didn't match without the length). Maybe I was unlucky (I know these rips have a high probability of scratch so I cannot really conclude anything from the fact that they don't match against CTDB, I will continue to test this as I find more rips like this in my collection) ... but my actual understanding of this result is that it means that there is an existing pressing with a datatrack which is the one in the CTDB & another pressing without which is mine. But something I don't understand is how these two pressing can have the same CTDB TOCID (unless I am wrong & these two supposed pressings are a single pressing) when one is detected by the CTDB as an enhanced CD & the other not detected as an enhanced CD by the old methodology based on cue sheet analysis.
Is the old way of detecting enhanced CD always right (even if it cannot guess the exact length without a log) or can it analyse an enhanced as a not enhanced CD by misstake (specially without a log) ?
I am asking because I am a little lost there. I don't know if the old method was always accurate about the presence or not of a datatrack so now my old .accurip log (based on AR database & cue sheet info, no log info) seems to conflict with my new ones (specially the CTDB added info).

At a lesser level (I only found 1 case so far) I noticed the same kind of conflict with the presence/length of pre-gap.

Code: [Select]
[Verification date: 28/04/2010 15:33:02]
[AccurateRip ID: 00148e86-00cdc11f-a20a200d] found.
Pregap length 00:00:33.
[CTDB TOCID: pcqRY4ScJAqkf0Xd2GWyYGrNFFU-] found.
        [ CTDBID ] Status
        [63c6f835] (67/67) Has pregap length 00:00:00


Wouldn't it be better if cuetools returned something less strict, like:
"CTDB reported pregap length 00:00:00, No match, you may have different pressing"
or
"CTDB reported data track length 08:57:40, No match, you may have different pressing"
instead of
"Is an Enhanced CD, data track length 08:57:40, No match"

Or am just wrong & the strict way of displaying the information is simply due to the fact that it is the absolute truth & then something is wrong in my rips ...

The actual wording is so inquisitive that it make you think that your rip is bad. I know that there are actually holes in my understanding & that I need to test more, but I have the intuition that my rip might be OK (no datatrack, not the same pre-gap) & that CTDB is giving me useless information about a pressing that is not mine just because the CTDBID is the same for the various pressings.

How is this CTDBID calculated ? specially does it use datatrack & pre-gap to avoid clash ?
There is obviously something that I am missing somewhere in order to understand what information is wrong which is right.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sonofdbn on 2010-04-29 03:44:58
Exception: failed to autodetect read command

That means that your CD drive model is not supported by CUERipper at this time  What is your CD drive model?


The DVD/CD drive is a Samsung - it says "Super Writemaster" on the front. Windows properties says it's a TSSTcorp CDDVDW SH-S223C. Is there a list of supported drives somewhere?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2010-04-30 07:12:17
Maybe a bit late, but I just found the pregap 32, 33, 37 script: Thank you very much!!! 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Respwaned2 on 2010-04-30 18:15:11
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself? If I set "audio output" to none in the image+cue mode and select "encode" for action, then nothing gets written to the output dir, except perhaps an accurip file.

The "correct filenames" action doesn't do this either. The "repair" custom script doesn't seem to do anything. The "Create cue sheet" action is disabled. The GUI of this otherwise fine program is rather confusing...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-04-30 20:25:53
Hi, Gregory.
This time it's not really questions but some suggestions for the log formatting.

Would it be possible to change the wording for "disk not present in database." to "disk not present in the AR database." & "disk not present in the CTDB database.", the reason why I am asking for this is because I do text based search within my .accurip log & then I sort my collection according to AR results in order to know what I neeed to re-check later.
With the new CTDB database results, now I got "false positive" mixing AR & CTDB results when I search for "disk not present in database." only.

Another possibility that would work for me too would be to add the possibilty to create two logs for the two database in order to not mix apples with oranges, one would be the old .accurip & the other a new .ctdb. It would be usefull to update logs against only 1 database if for exemple you know the other has not been updated. (How often is the CTDB updated ? Would be nice to have a page where you indicate when the database is updated.)

I think that I would also prefer to have the CTDB information displayed separatly at the end of the log instead of mixed within the AR information. I think it would be easier to read as the CTDBID is a useless information if the rip is not found which actually happen very often. Displaying first an information that is 99% of time useless is not really interesting IMHO, even if I understand that you want to promote your work.

Something like this: (with the ability to split the second part in a .ctdb, with the first line (date) duplicated in front of the .ctdb)
Code: [Select]
[Verification date: 30/04/2010 21:16:06]
[AccurateRip ID: 001e9b90-012dadbd-c80e170d] found.
Track [ CRC ] Status
 01 [e3912c21] (00/35) No match
 02 [f95bc3ed] (00/35) No match
 03 [273d76b9] (00/36) No match
 04 [51f86c5b] (00/36) No match
 05 [8731ef1d] (00/34) No match
 06 [c549489b] (00/34) No match
 07 [fe71fe3d] (00/35) No match
 08 [f02797bf] (00/34) No match
 09 [9a3de21a] (00/34) No match
 10 [49c5b587] (00/35) No match
 11 [b5d6e85b] (00/36) No match
 12 [6c615e51] (00/36) No match
 13 [5a17d925] (00/35) No match
Offsetted by -550:
 01 [f211be23] (04/35) Accurately ripped
 02 [0c8d5573] (04/35) Accurately ripped
 03 [cfe92cf7] (04/36) Accurately ripped
 04 [9d5d242f] (04/36) Accurately ripped
 05 [c62ad5cf] (04/34) Accurately ripped
 06 [623cc3c1] (04/34) Accurately ripped
 07 [b8ede7eb] (04/35) Accurately ripped
 08 [f68b20fd] (04/34) Accurately ripped
 09 [a6fa775e] (04/34) Accurately ripped
 10 [cd84208b] (04/35) Accurately ripped
 11 [e2d32ebd] (04/36) Accurately ripped
 12 [583c6daf] (04/36) Accurately ripped
 13 [ea63f575] (04/35) Accurately ripped
Offsetted by 126:
 01 [cda066d7] (31/35) Accurately ripped
 02 [d54f7a8f] (31/35) Accurately ripped
 03 [86a66ac3] (32/36) Accurately ripped
 04 [2e148cb7] (32/36) Accurately ripped
 05 [3b542463] (30/34) Accurately ripped
 06 [d92f4b1d] (30/34) Accurately ripped
 07 [1c559b17] (31/35) Accurately ripped
 08 [3b068cc9] (30/34) Accurately ripped
 09 [8ef21946] (30/34) Accurately ripped
 10 [f95267f3] (31/35) Accurately ripped
 11 [9ac70131] (32/36) Accurately ripped
 12 [102e40bb] (32/36) Accurately ripped
 13 [8be30995] (31/35) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98,3 [FB108FEE] [75CAFA3E]  
 01  98,3 [D75029BF] [66D74C6D]  
 02  98,0 [37ECA16C] [9269CE21]  
 03  92,5 [8A74C440] [9E42D327]  
 04  87,3 [0565D5DC] [36D6C0F5]  
 05  97,9 [A9FFE428] [E036EDD0]  
 06  97,9 [EDAEBB82] [F2AFD165]  
 07  93,7 [5711A02B] [136BFDDC]  
 08  87,3 [68B120D4] [CCE2F437]  
 09  88,2 [852FCA85] [6CD535D9]  
 10  98,0 [187CF52E] [385EAD54]  
 11  77,8 [0EB10F46] [699F23CA]  
 12  82,7 [3CB01ED5] [EB0A236E]  
 13  98,0 [5BD83527] [3DA8DD04]  

[CTDB TOCID: 0b_NoO0nHCBx3gDaIRQrUv.T_.U-] found.
[ CTDBID ] Status
[5323d943] (32/32) Accurately ripped

An exemple of .ctdb log:
Code: [Select]
[Verification date: 30/04/2010 21:16:06]
[CTDB TOCID: 0b_NoO0nHCBx3gDaIRQrUv.T_.U-] found.
[ CTDBID ] Status
[5323d943] (32/32) Accurately ripped

Also I think it's a bug when you repair a damaged rip, the created log reports how many error was fixed but then doesn't display the CTDBID anymore.
Code: [Select]
CUETools DB: corrected 1 errors.
<== no ID
should be
Code: [Select]
[CTDB TOCID: 0b_NoO0nHCBx3gDaIRQrUv.T_.U-] found. CUETools DB: corrected 1 errors.
        [ CTDBID ] Status
        [5323d943] (32/32) Accurately ripped

I corrected 12 rips so far it worked perfectly  Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-04-30 20:28:25
Maybe a bit late, but I just found the pregap 32, 33, 37 script: Thank you very much!!! 
I was curious about this and I have just tried on some files for which I had no CUE. It worked perfectly but I do not understand the result  . Since tracks 05 and 07 are accurately ripped with different offsets does this mean that the disk is accurately ripped ? Cheers.

Code: [Select]
[Verification date: 30.04.2010 21:12:31]
[AccurateRip ID: 00076572-002d3751-3c07a607] found.
Pregap length 00:00:33.
[CTDB TOCID: oe4Ur4VJ7xasTehb4QAJ5UzqGt0-] disk not present in database.
Track [ CRC ] Status
 01 [a96c48e0] (00/07) No match
 02 [028aebd8] (00/07) No match
 03 [85333568] (00/07) No match
 04 [599878db] (00/07) No match
 05 [56871c1a] (00/05) No match
 06 [77e9e338] (00/07) No match
 07 [049368f6] (00/07) No match
Offsetted by 6:
 01 [ec537bdf] (02/07) Accurately ripped
 02 [2e619264] (02/07) Accurately ripped
 03 [002691f3] (02/07) Accurately ripped
 04 [0c658b53] (02/07) Accurately ripped
 05 [f0629f1b] (00/05) No match
 06 [6ec5afe6] (02/07) Accurately ripped
 07 [36021af9] (02/07) Accurately ripped
Offsetted by 241:
 01 [b2d1c890] (05/07) Accurately ripped
 02 [10042ad8] (05/07) Accurately ripped
 03 [7a3724c0] (05/07) Accurately ripped
 04 [87c7fc7e] (05/07) Accurately ripped
 05 [f1647f91] (05/05) Accurately ripped
 06 [aef1fb70] (05/07) Accurately ripped
 07 [e2aa1c12] (05/07) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  59.1 [8CC66DE2] [12FF055A]  
 01  42.2 [6696F548] [F82756C3]  
 02  54.4 [C7A02353] [12AB9CD4]  
 03  32.7 [20A03151] [C4936B48]  
 04  57.3 [72ADE489] [EFA85717]  
 05  57.1 [F0526CF6] [1F2EB36F]  
 06  37.0 [8A7CF8A2] [377CA91C]  
 07  59.1 [47895623] [F0BD1265]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-04-30 20:38:56
prefab:
As far as I understand, as a whole your rip cannot actually be said as Accurate as there is no pressing in the database that matches yours, but it is likely that you have a 3 third pressing & it is likely to be accurate when it will be included in the database. Your rip is not accurate yet but is unlikely to be scratched.


See the two logs below: same rip with 5 months interval, it was the same case as yours (not AR) but is now perfectly AR.
Code: [Select]
[Verification date: 16/11/2009 02:21:59]
[Disc ID: 00210f7e-02fdcc77-9b0c8720]
Track [ CRC ] Status
 01 [a7fb1eab] (02/04) Accurately ripped
 02 [b3a7c02a] (02/04) Accurately ripped
 03 [5043d64c] (02/04) Accurately ripped
 04 [d49735a4] (03/05) Accurately ripped
 05 [d86d3c18] (02/04) Accurately ripped
 06 [830e3ecc] (02/04) Accurately ripped
 07 [3da68be2] (02/04) Accurately ripped
 08 [80f91339] (02/04) Accurately ripped
 09 [ce487b6b] (02/04) Accurately ripped
 10 [4fdec324] (02/04) Accurately ripped
 11 [09cb09e7] (03/05) Accurately ripped
 12 [353ad669] (02/04) Accurately ripped
 13 [0aa9af4a] (02/04) Accurately ripped
 14 [452a355d] (02/04) Accurately ripped
 15 [dbb8b038] (02/04) Accurately ripped
 16 [bf92d5d2] (02/04) Accurately ripped
 17 [ddcb7c85] (02/04) Accurately ripped
 18 [6498ac4f] (02/04) Accurately ripped
 19 [3c898673] (02/02) Accurately ripped
 20 [6219ee4d] (02/04) Accurately ripped
 21 [3afc3bf3] (02/04) Accurately ripped
 22 [035f9674] (03/05) Accurately ripped
 23 [7dd15b3c] (02/04) Accurately ripped
 24 [0ad44af9] (02/04) Accurately ripped
 25 [592216bd] (02/04) Accurately ripped
 26 [64f127a6] (03/05) Accurately ripped
 27 [7b21c891] (02/04) Accurately ripped
 28 [baac2520] (02/04) Accurately ripped
 29 [6a1d067b] (02/04) Accurately ripped
 30 [4e4a4b29] (02/04) Accurately ripped
 31 [ed07232f] (02/04) Accurately ripped
 32 [57c3acfe] (02/02) Partial match
Offsetted by 1337:
 01 [b07c04c3] (02/04) Accurately ripped
 02 [15670431] (02/04) Accurately ripped
 03 [eee23ab4] (02/04) Accurately ripped
 04 [9bce3150] (02/05) Accurately ripped
 05 [9e59570f] (02/04) Accurately ripped
 06 [bf225a54] (02/04) Accurately ripped
 07 [d02321ee] (02/04) Accurately ripped
 08 [b33b4da5] (02/04) Accurately ripped
 09 [316f8a8c] (02/04) Accurately ripped
 10 [b5cd62db] (02/04) Accurately ripped
 11 [502bf103] (02/05) Accurately ripped
 12 [9e99f224] (02/04) Accurately ripped
 13 [afb5b33c] (02/04) Accurately ripped
 14 [5e3566e3] (02/04) Accurately ripped
 15 [87ec3019] (02/04) Accurately ripped
 16 [0fa2f5fa] (02/04) Accurately ripped
 17 [edbfd7a8] (02/04) Accurately ripped
 18 [7273eb07] (02/04) Accurately ripped
 19 [924474f7] (02/02) Partial match
 20 [e199cb23] (02/04) Accurately ripped
 21 [46f555fa] (02/04) Accurately ripped
 22 [3917dd66] (02/05) Accurately ripped
 23 [4527442a] (02/04) Accurately ripped
 24 [0064ab68] (02/04) Accurately ripped
 25 [de698c32] (02/04) Accurately ripped
 26 [55177f15] (02/05) Accurately ripped
 27 [6c1af3ec] (02/04) Accurately ripped
 28 [7c14ab5c] (02/04) Accurately ripped
 29 [a747ed0b] (02/04) Accurately ripped
 30 [99c1fab6] (02/04) Accurately ripped
 31 [507e5332] (02/04) Accurately ripped
 32 [a98ed15c] (02/02) Accurately ripped

Track [ CRC32  ] [W/O NULL]
 -- [E9A1C36C] [8F80EB50]
 01 [0E63E3DF] [64292950]
 02 [3EF5E1E6] [06454285]
 03 [0AAFDC73] [452969AF]
 04 [AB3F266A] [43CAE9E5]
 05 [2E2F2E1F] [72C36F69]
 06 [FD6C316D] [374C2E26]
 07 [B959EF2A] [79413473]
 08 [E5A1F0AF] [DD67566F]
 09 [D3133F07] [17BC30F1]
 10 [72781844] [2D8D81A3]
 11 [EAB20437] [467D885D]
 12 [44582A2C] [1CABC0DB]
 13 [FD482702] [37FF1385]
 14 [43100C34] [F7E821E3]
 15 [228190DD] [B5482DE4]
 16 [0320E350] [C31BBB93]
 17 [F732E6B1] [E1D4176A]
 18 [D32877A5] [7BD25F05]
 19 [6C475E87] [EB2BDA3D]
 20 [FA744D71] [A75EEE42]
 21 [76FAC36C] [AFB60702]
 22 [BAA7D354] [D5315C52]
 23 [E56DBB4F] [2B80D237]
 24 [3B7A20FD] [6A1A4FC0]
 25 [E331A23C] [71F0DC49]
 26 [A9DBB386] [FF2C0DAF]
 27 [C9C9B4B5] [75CA6331]
 28 [C51F24D4] [13BEE4A3]
 29 [DDC96944] [BB7144E4]
 30 [8FC5FBB9] [480B07AE]
 31 [02E5D1CA] [C49E0F21]
 32 [BF54BE9D] [6C242209]

[Verification date: 28/04/2010 14:51:28]
[AccurateRip ID: 00210f7e-02fdcc77-9b0c8720] found.
[CTDB TOCID: EkbCkFeMtEGBT3wexy0BJdDsZMo-] disk not present in database.
Track [ CRC ] Status
 01 [a7fb1eab] (02/05) Accurately ripped
 02 [b3a7c02a] (02/05) Accurately ripped
 03 [5043d64c] (02/05) Accurately ripped
 04 [d49735a4] (03/06) Accurately ripped
 05 [d86d3c18] (02/05) Accurately ripped
 06 [830e3ecc] (02/05) Accurately ripped
 07 [3da68be2] (02/05) Accurately ripped
 08 [80f91339] (02/05) Accurately ripped
 09 [ce487b6b] (02/05) Accurately ripped
 10 [4fdec324] (02/05) Accurately ripped
 11 [09cb09e7] (03/06) Accurately ripped
 12 [353ad669] (02/05) Accurately ripped
 13 [0aa9af4a] (02/05) Accurately ripped
 14 [452a355d] (02/05) Accurately ripped
 15 [dbb8b038] (02/05) Accurately ripped
 16 [bf92d5d2] (02/05) Accurately ripped
 17 [ddcb7c85] (02/05) Accurately ripped
 18 [6498ac4f] (02/05) Accurately ripped
 19 [3c898673] (02/04) Accurately ripped
 20 [6219ee4d] (02/05) Accurately ripped
 21 [3afc3bf3] (02/05) Accurately ripped
 22 [035f9674] (03/06) Accurately ripped
 23 [7dd15b3c] (02/05) Accurately ripped
 24 [0ad44af9] (02/05) Accurately ripped
 25 [592216bd] (02/05) Accurately ripped
 26 [64f127a6] (03/06) Accurately ripped
 27 [7b21c891] (02/05) Accurately ripped
 28 [baac2520] (02/05) Accurately ripped
 29 [6a1d067b] (02/05) Accurately ripped
 30 [4e4a4b29] (02/05) Accurately ripped
 31 [ed07232f] (02/05) Accurately ripped
 32 [57c3acfe] (00/02) No match
Offsetted by 1337:
 01 [b07c04c3] (03/05) Accurately ripped
 02 [15670431] (03/05) Accurately ripped
 03 [eee23ab4] (03/05) Accurately ripped
 04 [9bce3150] (03/06) Accurately ripped
 05 [9e59570f] (03/05) Accurately ripped
 06 [bf225a54] (03/05) Accurately ripped
 07 [d02321ee] (03/05) Accurately ripped
 08 [b33b4da5] (03/05) Accurately ripped
 09 [316f8a8c] (03/05) Accurately ripped
 10 [b5cd62db] (03/05) Accurately ripped
 11 [502bf103] (03/06) Accurately ripped
 12 [9e99f224] (03/05) Accurately ripped
 13 [afb5b33c] (03/05) Accurately ripped
 14 [5e3566e3] (03/05) Accurately ripped
 15 [87ec3019] (03/05) Accurately ripped
 16 [0fa2f5fa] (03/05) Accurately ripped
 17 [edbfd7a8] (03/05) Accurately ripped
 18 [7273eb07] (03/05) Accurately ripped
 19 [924474f7] (02/04) Accurately ripped
 20 [e199cb23] (03/05) Accurately ripped
 21 [46f555fa] (03/05) Accurately ripped
 22 [3917dd66] (03/06) Accurately ripped
 23 [4527442a] (03/05) Accurately ripped
 24 [0064ab68] (03/05) Accurately ripped
 25 [de698c32] (03/05) Accurately ripped
 26 [55177f15] (03/06) Accurately ripped
 27 [6c1af3ec] (03/05) Accurately ripped
 28 [7c14ab5c] (03/05) Accurately ripped
 29 [a747ed0b] (03/05) Accurately ripped
 30 [99c1fab6] (03/05) Accurately ripped
 31 [507e5332] (03/05) Accurately ripped
 32 [a98ed15c] (02/02) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98,9 [E9A1C36C] [8F80EB50]  
 01  97,9 [0E63E3DF] [64292950]  
 02  97,9 [3EF5E1E6] [06454285]  
 03  97,9 [0AAFDC73] [452969AF]  
 04  97,9 [AB3F266A] [43CAE9E5]  
 05  97,9 [2E2F2E1F] [72C36F69]  
 06  97,9 [FD6C316D] [374C2E26]  
 07  97,9 [B959EF2A] [79413473]  
 08  97,9 [E5A1F0AF] [DD67566F]  
 09  97,9 [D3133F07] [17BC30F1]  
 10  57,8 [72781844] [2D8D81A3]  
 11  97,9 [EAB20437] [467D885D]  
 12  97,9 [44582A2C] [1CABC0DB]  
 13  97,9 [FD482702] [37FF1385]  
 14  97,9 [43100C34] [F7E821E3]  
 15  97,9 [228190DD] [B5482DE4]  
 16  97,9 [0320E350] [C31BBB93]  
 17  97,9 [F732E6B1] [E1D4176A]  
 18  97,9 [D32877A5] [7BD25F05]  
 19  97,9 [6C475E87] [EB2BDA3D]  
 20  97,9 [FA744D71] [A75EEE42]  
 21  97,8 [76FAC36C] [AFB60702]  
 22  98,9 [BAA7D354] [D5315C52]  
 23  96,5 [E56DBB4F] [2B80D237]  
 24  98,9 [3B7A20FD] [6A1A4FC0]  
 25  98,9 [E331A23C] [71F0DC49]  
 26  98,9 [A9DBB386] [FF2C0DAF]  
 27  98,9 [C9C9B4B5] [75CA6331]  
 28  98,9 [C51F24D4] [13BEE4A3]  
 29  98,9 [DDC96944] [BB7144E4]  
 30  98,9 [8FC5FBB9] [480B07AE]  
 31  98,9 [02E5D1CA] [C49E0F21]  
 32  98,6 [BF54BE9D] [6C242209]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-04-30 20:53:42
prefab:
As far as I understand, as a whole your rip cannot actually be said as Accurate as there is no pressing in the database that matches yours, but it is likely that you have a 3 third pressing & it is likely to be accurate when it will be included in the database. Your rip is not accurate yet but is unlikely to be scratched.
sauvage78, that was exactly what I was trying to figure out  Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: serge22 on 2010-05-01 09:01:02
Hello Gregory !
For FLAC encoder appears two of FLAKE - libFlake & flake with a different compression levels. What is a difference ?
Which of them (libFLAC, libFlake, flake) to prefer ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-01 12:06:22
Another option to make the log easily searchable is to do inside the log the same thing as you're aleady doing in the batch log:
Code: [Select]
AR: : disk not present in database, CTDB: disk not present in database.

The batch log already specify to which database belongs the results, applied inside the log it would give something like this:
Code: [Select]
[Verification date: 29/04/2010 18:10:16]
[AccurateRip ID: 000c38f1-005434a4-610a4608] AR: disk not present in database.
[CTDB TOCID: FEKJkkZuSGXzJ9XOczjF7rznBrg-] CTDB: disk not present in database.


Also an option to limit the date only to month/year would be nice, because displaying day/hours prevents you from searching .accurip doublon while displaying day/hour is not really usefull when the AR database is only updated monthly.
Code: [Select]
[Verification date: XX/04/2010 XX:XX:XX]
would be enougth for me
If you use CDImage+"fix offset to highest in database" searching doublons with .accurip is more efficient than with CDImage.flac as the same album encoded with the same setting with F2K & Cuetools is likely to not have the same checksum, despite being identical. Also being much smaller than a CDImage.flac, a .accurip is much faster to process.
I agree this is a very particular way of using .accurip but it would be nice to have the option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2010-05-02 10:15:31
Gregory
Regarding "find pregap script"...
For the case when no enumerated pregaps yield a match against AR DB I'd like to have in the end a log with IDs for zero pregap and calculated CRCs.
I can't figure out how to do it 'cause for now the header always contains info about the last enumerated pregap, even if I set it to zero before calling processor.Go(). Maybe it is related to the fact that when I break pregaps' sort order I get "can't set negative offset" or something.
Also it would be helpful if the log could contain a list of tested pregaps.
Is it possible?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-05-02 10:45:23
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself?
I also would like to be able to do this. Cheers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lorem Ipsum on 2010-05-02 14:10:10
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself?
I also would like to be able to do this. Cheers.

I think what you're after is achieved when setting "Audio Output" to "None"

-- L. Ipsum
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Respwaned2 on 2010-05-03 23:35:55
Is there a way to use CUETools to update the (separate) cue sheet using info from Freedb/musicbrainz without re-encoding the audio file itself?
I also would like to be able to do this. Cheers.

I think what you're after is achieved when setting "Audio Output" to "None"

-- L. Ipsum


Yes, that works, sort of, as long as you leave the combo box under action to "default", use "encode" for action, "image+cue" for mode, and output to "none" as indicated above. It won't update the cue file in place, but will create a new one in the destination directory.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Steve Forte Rio on 2010-05-05 09:45:35
Hello! My question is:

What files CUERipper requires to work separetly from CUETools???
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-06 04:35:32
A few thoughts:

In some case "disk not present in database." is repeated twice without real use.
Worst, it is confusing as the second time is repeated in the middle of CTDB information while it is an AR information. IMHO, this is not really clear. As no CRC is displayed because the rip is not in the AR database, "disk not present in database." is still displayed next to CTDB information without pointing out that it is not belonging to the CTDB informations. At first I was confused personnaly .

Exemple:
Code: [Select]
[Verification date: 06/05/2010 04:54:04]
[AccurateRip ID: 00100325-008d29b0-a809970c] disk not present in database.
CD-Extra data track length 02:37:15 - 02:38:14.
[CTDB TOCID: iV0EDyEDBUTK5m1qP1duC.QkPfY-] found.
        [ CTDBID ] Status
        [b90da38a] (39/39) , Accurately ripped
Disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
--   97,8 [D7CE63F7] [D53620F4]          
01   84,0 [B6E48353] [51481335]          
02   90,8 [6AF45844] [79640A06]          
03   97,8 [60FC355C] [9D941685]          
04   87,6 [A97E2DBC] [B9DD6683]          
05   89,3 [E491D56E] [62468787]          
06   91,6 [B9CA1D1C] [1AA62050]          
07   89,8 [454B37CA] [EFACBDA6]          
08   95,0 [2948647D] [E0A78584]          
09   87,6 [86E97FED] [9A1E4147]          
10   88,5 [21754A50] [E2C6BFEC]          
11   89,6 [7489D97C] [C619A96D]


Even if not perfect, it would have been clearer if
"Track   [ CRC    ] Status" would have split CTDB & AR informations zone.
Example:
Code: [Select]
[Verification date: 06/05/2010 04:54:04]
[AccurateRip ID: 00100325-008d29b0-a809970c] disk not present in database.
CD-Extra data track length 02:37:15 - 02:38:14.
[CTDB TOCID: iV0EDyEDBUTK5m1qP1duC.QkPfY-] found.
        [ CTDBID ] Status
        [b90da38a] (39/39) , Accurately ripped
Track    [ CRC    ] Status
Disk not present in database.


But IMHO the best way to deal with this is to completely remove the second "Disk not present in database." which is now useless. All this is unexpected consequences of the introduction of CTDB informations in the middle of AR informations. That's why I would prefer to have it in the end with the possibility of splitting the log in two logs (.accurip .ctdb).
The only drawback of having the CTDB information at the end is that with CD with plenty of pressings it forces you to look at the bottom. If this is really an issue then display the CTDB information in absolute first place just after the first line (Date) because IMHO the actual way of splitting the AR information in two to artifially put the CTDB checksum next to the AR checksums is only making things harder to read IMHO. Specially as the CTDB database is actually very small.

Also I noticed an unoptimised behavior of Cuetools:
When you "Verify"+"only if found", cuetools doesn't display the possible data track length if one if found in the CTDB database, this is sub-obtimal because the reason why the CD is not found in the AR database might be that the data track length is missing. So in this case Cuetools doesn't display an important information for you. It's normal but it's paradoxal.

Example:
Verify+Only if found:
Code: [Select]
[Verification date: 06/05/2010 00:02:41]
[AccurateRip ID: 0016f8d6-00d48840-a50c040d] disk not present in database.
CD-Extra data track length 08:56:44 - 08:57:43.
[CTDB TOCID: jYPeHFZN6n2dunXqLH_YAlPVfIs-] found.

You wasted the exact data track length which is included in CTDB but not displayed.

Same Verify+Default:
Code: [Select]
[Verification date: 06/05/2010 04:49:01]
[AccurateRip ID: 0016f8d6-00d48840-a50c040d] disk not present in database.
CD-Extra data track length 08:56:44 - 08:57:43.
[CTDB TOCID: jYPeHFZN6n2dunXqLH_YAlPVfIs-] found.
        [ CTDBID ] Status
        [75314992] (40/78) Is an Enhanced CD, data track length 08:57:40, Accurately ripped
        [853a89a6] (38/78) Is an Enhanced CD, data track length 08:57:40, No match
Disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
--   99,4 [297DBA6E] [FB457C98]          
01   99,4 [55D2767C] [594EC380]          
02   99,4 [AE16827C] [4CECCE03]          
03   99,4 [89B41C5C] [3493DC21]          
04   99,4 [9DC6F91F] [DCE80902]          
05   99,4 [2AA3EF16] [E3749205]          
06   99,4 [124F5ADD] [2620D55A]          
07   99,4 [250BBA83] [982E88AE]          
08   99,4 [9EE7922B] [1CF6AAF0]          
09   99,4 [69DC48DF] [ACBE00DF]          
10   80,6 [E7AB247B] [57201234]          
11   99,4 [3B379612] [4EBC6F88]          
12   99,4 [5A324E99] [20437F56]


Conclusion:
In some case it might be usefull to display CTDB information even if the rip is not found in the AR database.
IMHO, it's either you always display the CTDB information by default or you introduce a new verify mode, something like "Verify+Only if found+Always display CTDB information no matter AR result".

Thx Greg.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SamS on 2010-05-06 04:57:08
Gregory,

I just wanted to pop back in here to let you know how well CUETools worked to cure my "extra 4096 samples of silence" problem.  Everything has been modified appropriately, tagged and backed up.

Your program has really saved me lots of hours and frustration.  Thank you so much.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-06 19:12:56
Hi, Greg, I have a request.

Could you state a mandatory way of storing the data track lenght for people not using .log. This would be usefull in order to update the . accurip without being forced to enter manually the data track lenght.

The easiest way to achieve this without re-inventing the wheel would be to simply automatically parse any existing .accurip for the "CD-Extra data track length XX:XX:XX." string.

Personnaly, I also store this precious information separatly in a .nfo, because actually I fear that I would lost this information by misstake if I would update the . accurip without thinking that this would actually erase this information.

So I would enjoy if an external file with this data could be parsed too. I use .nfo because I rename my .accurip as . txt in order to make them searchable & .log is obviously reserved for EAC log. So no .log no .txt leaves me with .nfo. I understand that some people might reserve . nfo for another use ... so you just have to state an extension that would basically be a disguised .txt that would only be used to store the extra data track length. Think of it a little like the correction file of wavpack lossy. I dunno something like .accudata would do the trick.

exemple:
CDImage.accudata
Code: [Select]
CD-Extra data track length 21:10:30.


With such a file you can never lose the data track length, no matter what you do.

Indeed if you decide to simply parse any existing .accurip for the "CD-Extra data track length XX:XX:XX." string, storing this info in an external .nfo or .accudata becomes almost useless.

Storing the data length information in an external file is actually only a trick to avoid the bad behavior of cuetools which actually erase this information if you re-check a rip after deleting the EAC log.

Edit:
About the inconsistency of data track lenght between CTDB & the old TOC analysis, I think I have found myself the answer by testing. The old TOC based analysis is more reliable & the new CTDB suggested data length is only an additionnal hint about the possible length. So the right way of using this information is to only test the CTDB suggested length if you don't have the exact lenght given by the old TC analysis (but only a range due to the absence of log). That's the way I understand things right now. CTDB helped me found 8 data track length so far, so thks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-05-06 21:21:25
I have a request, too. Regarding CUERipper. I think it should come with its own log layout and not emulate an EAC log. Time to emancipate!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2010-05-06 21:48:51
Perhaps something like this:

Code: [Select]
CUERipper v2.0.8 Copyright © 2008-10 Gregory S. Chudov
Extraction logfile from : 04/25/2010 22:38:06
Used drive              : TSSTcorp - CD/DVDW SH-W162C
Read offset correction  : 6
Read command            : BEh, 12h, BEh, 16 blocks at a time
Secure mode            : 1
Disk length            : 76:17:64
AccurateRip            : ok

TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  | 00:00:00 | 07:20:32 |        0    |    33031
        2  | 07:20:32 | 03:03:50 |    33032    |    46806
        3  | 10:24:07 | 03:55:14 |    46807    |    64445
        4  | 14:19:21 | 04:39:15 |    64446    |    85385
        5  | 18:58:36 | 05:08:50 |    85386    |  108535
        6  | 24:07:11 | 03:40:22 |    108536    |  125057
        7  | 27:47:33 | 04:52:47 |    125058    |  147004
        8  | 32:40:05 | 05:07:58 |    147005    |  170087
        9  | 37:47:63 | 04:09:64 |    170088    |  188826
      10  | 41:57:52 | 04:53:59 |    188827    |  210860
      11  | 46:51:36 | 05:23:17 |    210861    |  235102
      12  | 52:14:53 | 05:01:16 |    235103    |  257693
      13  | 57:15:69 | 06:22:02 |    257694    |  286345
      14  | 63:37:71 | 05:51:65 |    286346    |  312735
      15  | 69:29:61 | 06:48:03 |    312736    |  343338

    Track |  Pregap  | Indexes
    ---------------------------------------------------------
        1  | 00:02:00 |    1
        2  | 00:00:00 |    1
        3  | 00:00:00 |    1
        4  | 00:00:00 |    1
        5  | 00:00:00 |    1
        6  | 00:00:00 |    1
        7  | 00:00:00 |    1
        8  | 00:00:00 |    1
        9  | 00:00:00 |    1
      10  | 00:00:00 |    1
      11  | 00:00:00 |    1
      12  | 00:00:00 |    1
      13  | 00:00:00 |    1
      14  | 00:00:00 |    1
      15  | 00:00:00 |    1

Destination files
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\01. Spincycle _ Drug Games.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\02. Dj On _ Super Sexy Girl.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\03. Mazi _ Interplay.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\04. Timo Mass feat. Kelis _ Help Me (Locodice Dub).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\05. Mickey Blue Eyes _ Keep Me Safe.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\06. Jef Dam _ Soundtrack (Apollo Kids remix).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\07. Elijah _ Deep Soul Music.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\08. Funk Function _ Old Skool House Musik.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\09. Silver City _ 1969.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\10. O. C. B. _ Synchronicity.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\11. Briggs & Lievense _ Breakdown.flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\12. Neruda _ Alliance (Club mix).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\13. Moguai _ U Know Y (Starecase remix).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\14. Ian Ossia & Marc Mitchell _ 4 Day Haze (We Like The Music).flac
    C:\Rip\Mixed by Lucien Foort\2003 - Slice! Cd01\15. Silk _ U Spin Me.flac

[CTDB TOCID: if_KJdER9AK3C8IMtLmzhYuKTro-] found.
        [ CTDBID ] Status
        [954194ef] (3/3) Accurately ripped

AccurateRip summary

Track [ CRC    ] Status
 01 [8854259e] (02/02) Accurately ripped
 02 [e2ea23a7] (02/02) Accurately ripped
 03 [965806cb] (02/02) Accurately ripped
 04 [4cb54a51] (02/02) Accurately ripped
 05 [3e294d1b] (02/02) Accurately ripped
 06 [7559a491] (02/02) Accurately ripped
 07 [d686dc8e] (02/02) Accurately ripped
 08 [3532a44c] (02/02) Accurately ripped
 09 [821b2e0f] (02/02) Accurately ripped
 10 [eb36048d] (02/02) Accurately ripped
 11 [c8fa8dc0] (02/02) Accurately ripped
 12 [fe45b79a] (02/02) Accurately ripped
 13 [5646bb50] (02/02) Accurately ripped
 14 [eea5b438] (02/02) Accurately ripped
 15 [ad5395b4] (02/02) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98.5 [D3C8079D] [D38F0EA0]         
 01  97.0 [65287AEF] [B6C10FA7]         
 02  97.0 [CA853F6D] [88210CAA]         
 03  97.0 [DF17904F] [51641C76]         
 04  97.0 [3CC8C1E5] [94AFA0CB]         
 05  95.0 [F10E3B6C] [44DFA557]         
 06  95.0 [44BA1A2A] [B30C79D2]         
 07  97.0 [E886AE51] [DABC3CAC]         
 08  98.5 [96AF58F2] [776F7A86]         
 09  97.0 [33379FAF] [117E661D]         
 10  98.5 [8C5D0734] [71C07C76]         
 11  98.5 [577BD323] [4ED12F73]         
 12  97.0 [A7D78EB8] [436250EA]         
 13  97.9 [FE906FAF] [7B4F9BF5]         
 14  95.8 [BB82BD92] [92AF1297]         
 15  97.0 [FDCDE22A] [89F80092]         

End of status report


Hint: Untick the "EAC log" option. 

Personally I don't see a need for the EAC log option. Since CUERipper is different some of the "logged" settings are probably not even correct for CUERipper.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-05-06 22:47:58
Thank you very much for the updates Gregory!

Had an idea the other day, Do you think CueTools can be made to support generation of real EAC cuesheets from existing log files ?
(I assume it is possible if the gaps were detected & reported in the log file.)

PS: Still hoping for non system wide proxy support!

Thanks !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-05-06 23:09:44
Hint: Untick the "EAC log" option. 

Damn! Never used CUE Ripper that much, but when I did a few days ago, I believed the "EAC log" option was the only way to get a log, any log.

Since CUERipper is different some of the "logged" settings are probably not even correct for CUERipper.

I compared the EAC log by CUERipper with one by EAC and noticed some differences. Of course, the read mode setting can be ignored, also that it fakes an outdated version of EAC. Adapter ID was different. Can be easily fixed, but why?

The most obvious and hard-to-fix difference it not having a clue about lead-in/out read capabilities... it's a dead give away that the log was faked. I think CUE Ripper tries too hard to fake an EAC log and I don't see the reason why it should in the first place, except maybe that it makes comparing a faked EAC log by CUE Ripper and an original EAC log easy in a compare tool like WinDiff or WinMerge. Could be helpful for analyzing problematic CDs... but then it would be enough to just use a CUE Ripper log header and a EAC log body, because this is the part where all the relevant data is to be found for comparing logs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2010-05-08 20:42:18
Is there a way to get CueRipper to use different gap handling settings? I'd prefer to not have the HTOA file if there is a first track pre-gap. I know it can be fixed with CUETools, but it would be nice to have the option to do it the way you prefer while ripping.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lazlo Nibble on 2010-05-12 06:02:39
Would it be possible to add the actual peak value on top of the EAC-style "percentage" value? If you could include values for each channel and polarity for the peak (first sample of that value if there's more than one) that'd be even better.  It might make it clearer to people that the EAC values are just approximations...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-12 06:12:40
Just a suggestion:
Reporting the track length in the log would be usefull to understand why very short tracks (including non-null silent track) or non-silent special cases that are usually short (intro, interlude) often suddenly have a lower AR confidence. See this Topic (http://www.hydrogenaudio.org/forums/index.php?showtopic=80831&st=0&p=704774&#entry704774). It would not make those tracks more accurate, but it would give you an hint of why the track has a lower confidence level. I guess that the peak level would do the trick to guess that with non-null silent track, but i don't think it would work well (never tried) with non silent special cases.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-05-12 23:10:37
Would it be possible to support the POSTGAP command?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-05-12 23:20:49
I ripped a brand new CD, not in AR-database using CUERipper in secure (track) mode.

Why does it not appear in CTDB when I verify with CUETools?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-12 23:59:41
It should have, unless there were errors.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-05-13 00:01:38
It should have, unless there were errors.

Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 10. May 2010, 20:21

Unknown Artist / Unknown Title

Used drive  : HL-DT-ST DVDRAM GSA-T50L  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  3:39.16 |        0    |    16440 
        2  |  3:39.16 |  3:53.30 |    16441    |    33945 
        3  |  7:32.46 |  3:20.63 |    33946    |    49008 
        4  | 10:53.34 |  3:31.31 |    49009    |    64864 
        5  | 14:24.65 |  4:21.10 |    64865    |    84449 
        6  | 18:46.00 |  3:55.09 |    84450    |  102083 
        7  | 22:41.09 |  3:55.35 |    102084    |  119743 
        8  | 26:36.44 |  3:27.55 |    119744    |  135323 
        9  | 30:04.24 |  4:27.12 |    135324    |  155360 
      10  | 34:31.36 |  3:35.03 |    155361    |  171488 
      11  | 38:06.39 |  3:45.52 |    171489    |  188415 


Track  1

    Filename M:\Ripped\Unknown Artist - Unknown Title\01. Byens Bitreste Mand.wav

    Pre-gap length  0:00:02.00

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC D0F0AD80
    Copy CRC D0F0AD80
    Track not present in AccurateRip database
    Copy OK

Track  2

    Filename M:\Ripped\Unknown Artist - Unknown Title\02. Nitten.wav

    Peak level 100.0 %
    Track quality 100.0 %
    Test CRC C373B930
    Copy CRC C373B930
    Track not present in AccurateRip database
    Copy OK

Track  3

    Filename M:\Ripped\Unknown Artist - Unknown Title\03. Selvmord På Dansegulvet.wav

    Pre-gap length  0:00:01.36

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 2C5EF57A
    Copy CRC 2C5EF57A
    Track not present in AccurateRip database
    Copy OK

Track  4

    Filename M:\Ripped\Unknown Artist - Unknown Title\04. En Stivnet Smiler.wav

    Pre-gap length  0:00:01.40

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC D4DAAA5D
    Copy CRC D4DAAA5D
    Track not present in AccurateRip database
    Copy OK

Track  5

    Filename M:\Ripped\Unknown Artist - Unknown Title\05. Hvad Mere Vil Du Have.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 874356FF
    Copy CRC 874356FF
    Track not present in AccurateRip database
    Copy OK

Track  6

    Filename M:\Ripped\Unknown Artist - Unknown Title\06. Almindelige Mennesker.wav

    Pre-gap length  0:00:01.90

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC BF2E47D2
    Copy CRC BF2E47D2
    Track not present in AccurateRip database
    Copy OK

Track  7

    Filename M:\Ripped\Unknown Artist - Unknown Title\07. Lidt For Lidt.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 9AB4A9D2
    Copy CRC 9AB4A9D2
    Track not present in AccurateRip database
    Copy OK

Track  8

    Filename M:\Ripped\Unknown Artist - Unknown Title\08. Middelklassehelt.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 72EF1A85
    Copy CRC 72EF1A85
    Track not present in AccurateRip database
    Copy OK

Track  9

    Filename M:\Ripped\Unknown Artist - Unknown Title\09. Samtalekøkken.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 6EF0885D
    Copy CRC 6EF0885D
    Track not present in AccurateRip database
    Copy OK

Track 10

    Filename M:\Ripped\Unknown Artist - Unknown Title\10. Har Du Forstået.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC 0CE2691C
    Copy CRC 0CE2691C
    Track not present in AccurateRip database
    Copy OK

Track 11

    Filename M:\Ripped\Unknown Artist - Unknown Title\11. Mere Endnu.wav

    Peak level 99.9 %
    Track quality 100.0 %
    Test CRC A899E175
    Copy CRC A899E175
    Track not present in AccurateRip database
    Copy OK


None of the tracks are present in the AccurateRip database

No errors occurred

End of status report
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-13 00:26:17
Well, sometimes connection can break during uploading, but according to log the only time this happened last week was 11/May/2010:21:59:29 +0400
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: onkl on 2010-05-13 07:19:34
I guess it's the same issue sauvage78 reported:

Code: [Select]
[AccurateRip ID: 000cef35-004de6cd-540bec08] disk not present in database.
CD-Extra data track length 18:23:00 - 18:23:74.
[CTDB TOCID: zj_rMxHuJN5Oerzcxqxr2bsS22A-] found.
        [ CTDBID ] Status
        [400e759b] (12/12) Is an Enhanced CD, data track length 18:23:25, Accurately ripped      <--------
Disk not present in database.


It's not clear whether the disk is accuratly ripped or not in the database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-13 08:12:23
onkl:
With this log you actually cannot say if the rip is accurate or not because your EAC log is missing the exact data track length ... so cuetools only guess a range of possible lengths:
Code: [Select]
CD-Extra data track length 18:23:00 - 18:23:74.

but you're lucky because CTDB includes your CD & gives you  a big hint of this exact data track length:
Code: [Select]
data track length 18:23:25


Just put this number in Cuetools data track length's box & re-check, if the rip is in the AR database then you will know if it is accurate or not.

CTDB is great for reparing but it is also great to get the exact data track length.

My personnal issue was that I didn't knew which one to trust in case cuetools doesn't detect a range but CTDB detect an enhanced CD, I have tried to get an answer by experimentation, obviously in this case cuetools is right & you just happen to have a non-enhanced pressing of the enhanced CD which is in the database. So in this case, if cuetools doesn't detect a range, it seems that you should just ignore the CTDB enhanced information.

Edit: lot of typos.

The mandatory way of storing (& parsing) the exact data track length in an external file that I was asking for earlier (I use .nfo actually) or the ability of cuetools to parse .accurip for this information (in case you delete the EAC log after checking AR with cuetools) would be usefull for guys like me in order to submit to CTDB. Because as I don't use logs, if I actually submit my enhanced CD to CTDB I fear that it will not work as it should as there will be no data track length.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: onkl on 2010-05-13 17:08:59
Hey that did the trick! With the data track info AR could verify the rip. Thanks for the advice. Now I wonder why CUETools doesn't recheck by itself.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Thundik81 on 2010-05-15 10:17:46
I'm re-ripping with CUETools few CDs that are not in any DB (musicbrainz, freedb, AMG, ...).

Feature request :
Could you import tags from files (in this case , *.flac , individual tracks) ?

I failed to rip a bonus track (#21).
TOC :
      20  | 64:12.56 |  4:02.60 |    288956    |  307165 
      21  | 70:47.41 |  6:38.34 |    318566    |  348449 
Drive used : HL-DT-ST DVDRAM GSA-T40N
[Copy range didn't work in EAC either]

Is it a drive limitation ? Should i try with another drive ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-05-15 17:28:35
I'm re-ripping with CUETools few CDs that are not in any DB (musicbrainz, freedb, AMG, ...).

You can also scan the old rips with CUE Tools, and if the AR confidence is greater than 2 the CTDB hashes can be submitted to the database. That should be a timesaver.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Thundik81 on 2010-05-15 19:06:50
You can also scan the old rips with CUE Tools, and if the AR confidence is greater than 2 the CTDB hashes can be submitted to the database. That should be a timesaver.


As i said : AccurateRip: disk not present in database.

Edit: however how to update cue files created by EAC without re-ripping ? (i want to add ACCURATERIPID, CATALOG and ISRC)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-16 08:26:23
The mandatory way of storing (& parsing) the exact data track length in an external file that I was asking for earlier (I use .nfo actually) or the ability of cuetools to parse .accurip for this information (in case you delete the EAC log after checking AR with cuetools) would be usefull for guys like me in order to submit to CTDB. Because as I don't use logs, if I actually submit my enhanced CD to CTDB I fear that it will not work as it should as there will be no data track length.

There are too many ways to organize your rips, CUETools cannot possibly be 'smart' enough to guess it in each case. Keeping the log file is the most common and reliable way. You can at least keep the TOC portion of the log at least for enhanced CDs. It seems somehow wrong to use .accurip files for verification when they are the result of verification. Besides, .accurip format is changing frequently, many people store .accurip files not in the same folder as the rip, it also often has a different extension.

Hey that did the trick! With the data track info AR could verify the rip. Thanks for the advice. Now I wonder why CUETools doesn't recheck by itself.

As sauvage78 pointed out, data track length from CTDB is not always relevant (you can have a non-enhanced pressing of the enhanced CD which is in the database). But in this particular case when CUETools knows that there is a data track but doesn't know it's exact length, i suppose it makes sense to use CTDB info. I'll probably implement it.

Could you import tags from files (in this case , *.flac , individual tracks) ?

The best solution would probably be to submit metadata from flac rip to freedb or musicbrainz, i'm sure it's possible with some software. CUETools will probably soon be able to submit to freedb. You could then import those tags when reripping.

I failed to rip a bonus track (#21).
TOC :
      20  | 64:12.56 |  4:02.60 |    288956    |  307165 
      21  | 70:47.41 |  6:38.34 |    318566    |  348449

It's not a bonus audio track, it's a data track. It contains files, and it can be copied using explorer.

Edit: however how to update cue files created by EAC without re-ripping ? (i want to add ACCURATERIPID, CATALOG and ISRC)

One of the awkward ways to do this is to start ripping and abort after gaps are detected. CUERipper has already written .cue at this point. You could then just replace old .cue with new. It should be compatible with old files, if you used the same mode (image or tracks).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Thundik81 on 2010-05-16 08:44:30
Could you import tags from files (in this case , *.flac , individual tracks) ?

The best solution would probably be to submit metadata from flac rip to freedb or musicbrainz, i'm sure it's possible with some software. CUETools will probably soon be able to submit to freedb. You could then import those tags when reripping.


thanks. Nice forthcoming feature.

I failed to rip a bonus track (#21).
TOC :
      20  | 64:12.56 |  4:02.60 |    288956    |  307165 
      21  | 70:47.41 |  6:38.34 |    318566    |  348449

It's not a bonus audio track, it's a data track. It contains files, and it can be copied using explorer.


That's what i assumed for this "bonus" track. I thought that audio ripping tool could retrieve that kind of data... no problem i'll use Isobuster or such a software.

Edit: however how to update cue files created by EAC without re-ripping ? (i want to add ACCURATERIPID, CATALOG and ISRC)

One of the awkward ways to do this is to start ripping and abort after gaps are detected. CUERipper has already written .cue at this point. You could then just replace old .cue with new. It should be compatible with old files, if you used the same mode (image or tracks).


I would love an update cue function (like the Correct extension / filenames) 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-16 10:04:31
Gregory S. Chudov:
Quote
There are too many ways to organize your rips


Well you're forgetting that you can have an EAC log & still miss the exact data track length, the TOC & data track length is only included in rips with recent EAC log ... I have plenty of rips with old EAC log which don't inludes the data track length ... these rips are perfectly valid & I haven't done any misstake.

There must be a mandatory way to store the exact data lengtht for rip with old EAC log (or no log at all which in the end is the same) ... you cannot just tell me "hey, it's you're fault, just use EAC log!" This is not true. 80% of my logs didn't have a TOC, so it would have been the same if I would have keept those logs.

I understand that parsing a .accurip might sound weird to you if you only have logs with TOC & don't miss any exact data track length ... but for old EAC rips with the old EAC log formatting this is [Edit: maybe] where it belongs [Edit: In fact I don't think so, see below]... I mean you cannot store it in the log unless you heavily edit it & it is never a good idea to edit a log.

(Long off-topic parenthesis about my position on logs:
I delete logs specially for this reason: my logs are perfect so those are of no use for me, & I know I cannot trust any logs from anyone except me so why would I keep those logs too? Keeping EAC logs is IMHO just a FUD from zealots which don't understand the information included inside, & specially that don't admit that a rip with "no error" in the EAC log can be scratched. Don't get me wrong I don't think logs are useless, I think that logs are only usefull when something is wrong & I have checked all my logs for anything wrong before deleting them, so my logs are not useless, those are just not usefull to me anymore. IMHO, the people who only swear by EAC logs are P2P irrationnal teenagers sectarians, the same kind so-called audiophile which were enforcing the use of Musepack a few years ago. It's not that keeping logs would be stupid, if I would not verify my logs instantly I would keep those untill I would check them. So even if I don't keep those I do create them, I wouldn't even create those if I would think those would be completely useless. I have keept my logs for years before experience told me that those files weren't as precious as I was told.)

Back on the topic:
So as the exact data track length is not included in old EAC logs & as you cannot store the exact data length in .log without editing (& as furthermore editing would be a painfull waste of time) ... you have to find an official simple yet efficient way to store this information ... you cannot say : "You don't organize your collection like me, it's your fault" ... It is not my fault if early EAC logs don't work well with AR & Cuetools, I am only asking for a simple solution.

I admit that, for the same reason as editing an EAC log, editing a .accurip is not a good idea, manually editing a .accurip for parsing is strange ... still manually adding  the line "CD-Extra data track length XX:XX:XX." & re-checking with a Cuetools version that would parse this info before any calculation, is one of the two easiest solutions I found.

In the end the conlusion is simple:
If you admit that you must find a solution for enhanced CD with early EAC log, I only see 2 choices ...
1- You don't want to store this info outside the .accurip, then you have to accept the idea of . accurip editing in this special case & parse . accurip for this info.
2- You don't want people to edit .accurip even in this special case, then you have to admit the idea of parsing an external file with this information to simulate the .log. This .txt can be a .nfo, a .accudata or a .whatever-you-want ... it doesn't matter to me but I think it would be better to have a new extension reserved for this use ... because some people might already use .log/.txt/.nfo for other purposes.

I understand that this is boring & annoying for you ... you have to code something you obviously don't use & both solutions have flaws (additionnal parsing, editing or additionnal file) ... but you cannot tell that the problem doesn't exist, it just doesn't exist for you. Personnaly I already use .nfo, so I think the second solution with the parsing of an external .accudata file is the best solution. I don't like the idea of editing . accurip from the first solution.

Now you may ask why am I asking for this if I already use .nfo ? The reason is simple, if you don't automaticaly parse an external file for the exact data track lenght then you force people to manually add this length ... with only a few enhanced CD, in the beginning it was not an issue ... but I have realized that I had ~100 enhanced rips so this has became an issue for me ... worse now I don't know if I can upload those ECD to CTDB as I don't know how it will react (Will it create a non enhanced pressing that don't exist in real life? It is an issue at all?).

I understand that you must have plenty of more important stuff to code first, but I disagree with the denial of the problem for enhanced CD with old EAC logs.

Edit:
Think of it as wavpack lossy+correction file (.wv+.wvc) ... (.accurip+.accudata) ... simple & efficient.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-16 12:34:54
After you added CD to CTDB, CUETools will always be able to get data track length from there. I just added this feature. So in this case it becomes unnecessary to store it in any file. And when you don't use CTDB, stored ACCURATERIPID tag is enough.

There remains only one exotic case where you might want to store data track length - when you have an old rip which cannot be submitted to CTDB at this time (inaccurate/not in AR database), but you want to be able to try again later. Personally i think this case is unimportant. But just in case i will add support for .toc files, which contain TOC portion of EAC log. I'll even add an option to create such files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-16 15:12:14
Well I'll wait to see how this get implemented to comment, but if you can create a .toc which includes the data track length (manually added but once for good at .toc creation this time) & if Cuetools can parse it instead of .log when the log is missing then I guess it should perfectly fit my needs ... if this works that way then I will instantly creates .toc for all my ECD for which I know the data track length ... I may even start to search manually some of those I miss ... actually the most annoying thing about my ECD is that I have to manage them in a seperate folders as some of them have a data track length & some don't, & even for those which have an exact data length but no log, I cannot update the AR count as I have no way to automatically parse the information.

It might sound exotic to you, but it highly depends on how many ECD you ripped before EAC log included the TOC ... this is a must have feature for me as each special AR case is splitting my collection in different folders actually.

It's true that creating an additionnal separate file just for one line "CD-Extra data track length XX:XX:XX." creates files that are almost empty, I have nothing against adding the TOC, I just didn't thought about it. Afterall that's the only part of EAC logs that I am truly missing ... in fact I didn't thought about this option as I thought that creating a complete TOC would have useless work for you when a simple copy/paste can do the trick, but if you're willing to add it that way because it sound more logic to you ... I am all in.

To a lesser extand I have the same problem with rips with silent track:
as Cuetools doesn't detect an accurate rip with confidency 3 as accurate if it includes a [00000000] silent track, it rejects those rips from CTDB ...
Code: [Select]
CDImage.cue: AccurateRip: confidence too low.
Those rips are perfectly AR3.
Code: [Select]
[Verification date: 05/05/2010 23:02:52]
[AccurateRip ID: 0018549a-00e1dd40-aa0cfc0c] found.
[CTDB TOCID: QZ8He3MyR7ifg.FPwQlph_aAmL8-] disk not present in database.
Track [ CRC    ] Status
 01 [9a81e41e] (05/05) Accurately ripped
 02 [60fc2f70] (05/05) Accurately ripped
 03 [18200767] (05/05) Accurately ripped
 04 [d72a42f2] (05/05) Accurately ripped
 05 [6ebb67af] (05/05) Accurately ripped
 06 [1c245330] (05/05) Accurately ripped
 07 [00000000] (00/00) No match
 08 [a6096bc8] (05/05) Accurately ripped
 09 [a647b5ab] (05/05) Accurately ripped
 10 [919a1bc5] (05/05) Accurately ripped
 11 [94611876] (05/05) Accurately ripped
 12 [1121b507] (05/05) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98,8 [7255B76C] [CF9A3606]         
 01  98,8 [5A6F00EA] [BF508009]         
 02  98,5 [54ACC1C8] [5A96293A]         
 03  98,8 [1591BC51] [7AD4DC9B]         
 04  98,8 [4D09A800] [361B02A7]         
 05  98,8 [C250DD50] [049BD2DA]         
 06  98,8 [8B532B12] [406D5C1D]         
 07    0,0 [02864C0E] [00000000]         
 08  98,8 [915367D2] [4DE0C500]         
 09  98,8 [CFB8B562] [316B64D9]         
 10  98,8 [C48522CC] [FBE5E4CE]         
 11  98,8 [5640892A] [A0A973E7]         
 12  98,8 [3C7DB066] [15D83CA3]         

 At some point, (after Sandy Bridge CPU are released, so around 2011) I plan to submit all my collection to CTDB. I hope those rips could be submitted, even if those "exotic cases" are "unimportant" ... I'll keep those in a separate folder too till then ...

Here is a list of "unimportant" rips that I actually cannot submit to CTDB even if I wanted to
Code: [Select]
Danzig - 1994 - Danzig 4
Edge Of Sanity - 1994 - Purgatory Afterglow
John Lennon - 1973 - Mind Games
Korn - 1998 - Follow The Leader
Marilyn Manson - 1996 - Antichrist Superstar
Mayhem - 2000 - Grand Declaration Of War
Ministry - 1999 - Dark Side Of The Spoon
Morbid Angel - 2003 - Heretic
Nine Inch Nails - 1992 - Broken (EP, Digipack)
Overkill - 1994 - W.F.O.
Tool - 1993 - Undertow
Louis Armstrong - 2008 - The Hot Five & Hot Seven Recordings (1925-29) (4CD)
Marillion - 2008 - Happiness Is The Road (2CD, Deluxe Ed)

I could post twice more but I am bored of copy pasting

I may look constantly complaining ... but don't get me wrong I am already very thanksfull for all you achieved with Cuetools, in fact I am addicted to it ... it's just that it could be even better !!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-18 18:26:39
To a lesser extand I have the same problem with rips with silent track:
as Cuetools doesn't detect an accurate rip with confidency 3 as accurate if it includes a [00000000] silent track, it rejects those rips from CTDB ...

Thanks, fixed in 2.0.9
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-18 18:49:59
Thanks

Honestly I wish that rips with [00000000] would not only be accepted as submissions but also that those rips would be reported as accurate in the bach log because actually when I "fix" my rips according to the offset with the highest AR confidence  in database+only if 100% tracks are AR2+only if all tracks match the same offset ... cuetools doesn't "fix" the offset too (as so far a rip with [00000000] couldn't be accurate no matter the result of the others non-silent tracks) [Edit: I guess I can lower the required confidence but it forces me to do 2 pass]

In fact I wish that [00000000] tracks would be simply ignored no matter the action. Both when you set an AR confidence parameter as a filter & when cuetools draw a conclusion about the accuracy of the whole disk.

Edit: My personnal assistant Greynol just told me that the word "confidency" didn't exist  Fixed to "confidence", thks !!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-18 19:42:16
I just saw that V2.09 was actually released so I tested it ... I succesfully submitted a rip with an empty track to CTDB so that part worked ... but after that I tried to "fix" another rip & I had a strange result: all tracks are now reported as accurate in the .accurip log but the batch log still concludes that the whole rip is not accurate & so the whole offset fixing didn't start, then I tried to upload that "bad" rip ... & it was accepted (Edit: The first time I didn't check if the whole rip was accurate in the batch log before being accepted, despite being accepted it "wasn't accurate" in batch log too I just re-checked):

Batch log: Bad hence "offset not fixable" with my filter
Code: [Select]
CDImage.cue: AR: rip not accurate (16/16).

Bad but submitted ???
Code: [Select]
CDImage.cue: AR: rip not accurate (16/16), CTDB: disk not present in database, zImXwBUC_ZGAOhJghadou315CbE- has been uploaded.

.accurip log: Good but should have been "fixed" by +66 if [00000000] tracks would have been ignored.
Code: [Select]
[CUETools log; Date: 18/05/2010 20:23:30; Version: 2.0.9]
[AccurateRip ID: 0032ca87-03021fa3-4909bb17] found.
Track  [ CRC    ] Status
 01    [25b0fccd] (05/19) Accurately ripped
 02    [f926c883] (05/19) Accurately ripped
 03    [3220d10e] (05/19) Accurately ripped
 04    [0b9512be] (05/19) Accurately ripped
 05    [0bd9f5a4] (05/19) Accurately ripped
 06    [b695892c] (05/19) Accurately ripped
 07    [59d33144] (05/19) Accurately ripped
 08    [9ef4928e] (05/19) Accurately ripped
 09    [beee4d2c] (05/19) Accurately ripped
 10    [a82efa2d] (05/19) Accurately ripped
 11    [4b5fb83b] (06/20) Accurately ripped
 12    [00000000] (00/00) Accurately ripped
 13    [00000000] (00/00) Accurately ripped
 14    [00000000] (00/00) Accurately ripped
 15    [00000000] (00/00) Accurately ripped
 16    [00000000] (00/00) Accurately ripped
 17    [00000000] (00/00) Accurately ripped
 18    [00000000] (00/00) Accurately ripped
 19    [00000000] (00/00) Accurately ripped
 20    [00000000] (00/00) Accurately ripped
 21    [00000000] (00/00) Accurately ripped
 22    [00000000] (00/00) Accurately ripped
 23    [09c3e978] (05/16) Accurately ripped
Offsetted by 66:
 01    [4c7144a7] (14/19) Accurately ripped
 02    [6999bd94] (14/19) Accurately ripped
 03    [efc0b09a] (14/19) Accurately ripped
 04    [a3b20f25] (14/19) Accurately ripped
 05    [b62a4303] (14/19) Accurately ripped
 06    [131b76eb] (14/19) Accurately ripped
 07    [2716707c] (14/19) Accurately ripped
 08    [5122279f] (14/19) Accurately ripped
 09    [bcefe72c] (14/19) Accurately ripped
 10    [183f759e] (14/19) Accurately ripped
 11    [469135c7] (14/20) Accurately ripped
 12    [00000000] (00/00) Accurately ripped
 13    [00000000] (00/00) Accurately ripped
 14    [00000000] (00/00) Accurately ripped
 15    [00000000] (00/00) Accurately ripped
 16    [00000000] (00/00) Accurately ripped
 17    [00000000] (00/00) Accurately ripped
 18    [00000000] (00/00) Accurately ripped
 19    [00000000] (00/00) Accurately ripped
 20    [00000000] (00/00) Accurately ripped
 21    [00000000] (00/00) Accurately ripped
 22    [00000000] (00/00) Accurately ripped
 23    [ea572e0b] (11/16) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [02D97771] [08042A49]         
 01  100,0 [1D2F1FB9] [F51F0F51]         
 02  100,0 [2553F3A4] [523834A1]         
 03  100,0 [A7A5FC78] [4912C60B]         
 04  100,0 [5E7313D1] [92089105]         
 05  100,0 [2E581386] [E97B4DCA]         
 06  100,0 [B05D8912] [796EE265]         
 07  100,0 [C1AF8AA1] [3FE268F4]         
 08  100,0 [D9805A37] [8FD46487]         
 09  100,0 [97FB0799] [DFB237D8]         
 10  100,0 [CDAEDC9F] [E7A1BCEC]         
 11  100,0 [790C0F58] [9E32BA87]         
 12    0,0 [6E375D99] [00000000]         
 13    0,0 [6E375D99] [00000000]         
 14    0,0 [6E375D99] [00000000]         
 15    0,0 [6E375D99] [00000000]         
 16    0,0 [6E375D99] [00000000]         
 17    0,0 [6E375D99] [00000000]         
 18    0,0 [6E375D99] [00000000]         
 19    0,0 [6E375D99] [00000000]         
 20    0,0 [6E375D99] [00000000]         
 21    0,0 [6E375D99] [00000000]         
 22    0,0 [6E375D99] [00000000]         
 23  73,3 [AE335FE7] [ED630E95]         


... there is actually a problem of logic in the way things are reported IMHO

Edit: Also instead of "Accurately ripped" reporting as "Silent track" would IMHO be better for newbies which doesn't understand what [00000000] means.
Edit2: If you want to be even more precise & make a difference between silent track with data (not empty) & silent track without data (empty), maybe someting like "Empty track" or "No data" would work too. I don't know if the precision is really usefull.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2010-05-19 00:13:14
CUETools 2.0.8 and 2.0.9 are not working for me under mono.


~/smb/CUETools_2.0.9$ mono ArCueDotNet.exe /tmp/Estatic\ Fear\ -\ Somnium\ Obmutum.flac.cue
Error: Access to the path "/tmp/orbit-root" is denied.

For some reason it needs to scan every file in that directory....

~/smb/CUETools_2.0.9$ mono ArCueDotNet.exe /tmp/arcue/Estatic\ Fear\ -\ A\ Sombre\ Dance.flac.cue
Error: Array index is out of range.


~/smb/CUETools_2.0.4a_x86$ mono ArCueDotNet.exe /tmp/Estatic\ Fear\ -\ Somnium\ Obmutum.flac.cue
[Verification date: 5/18/2010 3:59:15 PM]
[Disc ID: 000901b5-00255800-1b0d5604]
.....

I'm not sure what version broke it for mono. Any chance someone can look into this? Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-19 06:22:29
I'll try...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marooned on 2010-05-19 23:09:34
I used to be able to associate .cue files with cuetools but since upgrading to 2.0.9 I can't anymore.  Anybody else having this problem?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-20 09:05:31
Me not. Check the path. I have the following in my registry and it works:

[HKEY_CLASSES_ROOT\Folder\shell\cue tools]
"" = "Browse with CUETools"

[HKEY_CLASSES_ROOT\Folder\shell\cue tools\command]
"" = "C:\Work\cuetoolsnet\bin\Release\CUETools.exe" "%1"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-05-20 13:01:35
I found a CD in my collection where CUE Ripper cannot detect pre-gaps. What I do?

Code: [Select]
REM ACCURATERIPID 00211583-01624bb2-c70ed90e
REM DISCID C70ED90E
REM COMMENT "CUERipper v2.0.9 Copyright © 2008-10 Gregory S. Chudov"
REM DATE 1991
REM GENRE "Industrial"
PERFORMER "Die Warzau"
TITLE "Big Electric Metal Bass Face"
FILE "01. Crack Radio.wv" WAVE
  TRACK 01 AUDIO
    TITLE "Crack Radio"
    PERFORMER "Die Warzau"
    PREGAP 00:00:33
    INDEX 01 00:00:00
FILE "02. Funkopolis.wv" WAVE
  TRACK 02 AUDIO
    TITLE "Funkopolis"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "03. Never Again.wv" WAVE
  TRACK 03 AUDIO
    TITLE "Never Again"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "04. Shock Box.wv" WAVE
  TRACK 04 AUDIO
    TITLE "Shock Box"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "05. Brand New Convertible Car.wv" WAVE
  TRACK 05 AUDIO
    TITLE "Brand New Convertible Car"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "06. Burning.wv" WAVE
  TRACK 06 AUDIO
    TITLE "Burning"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "07. All Cut Up.wv" WAVE
  TRACK 07 AUDIO
    TITLE "All Cut Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "08. Coming Down (Live).wv" WAVE
  TRACK 08 AUDIO
    TITLE "Coming Down (Live)"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "09. My Pretty Little Girlfriend.wv" WAVE
  TRACK 09 AUDIO
    TITLE "My Pretty Little Girlfriend"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "10. Red All Over.wv" WAVE
  TRACK 10 AUDIO
    TITLE "Red All Over"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "11. Pig City.wv" WAVE
  TRACK 11 AUDIO
    TITLE "Pig City"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "12. Dying in Paradise.wv" WAVE
  TRACK 12 AUDIO
    TITLE "Dying in Paradise"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "13. Suck It Up.wv" WAVE
  TRACK 13 AUDIO
    TITLE "Suck It Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "14. Head.wv" WAVE
  TRACK 14 AUDIO
    TITLE "Head"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00

Code: [Select]
REM GENRE rock
REM DATE 1991
REM DISCID C70ED90E
REM COMMENT "ExactAudioCopy v0.99pb5"
CATALOG 0731451198823
PERFORMER "Die Warzau"
TITLE "Big Electric Metal Bass Face"
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\01. Crack Radio.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Crack Radio"
    PERFORMER "Die Warzau"
    PREGAP 00:00:33
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\02. Funkopolis.wav" WAVE
  TRACK 02 AUDIO
    TITLE "Funkopolis"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\03. Never Again.wav" WAVE
  TRACK 03 AUDIO
    TITLE "Never Again"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\04. Shock Box.wav" WAVE
  TRACK 04 AUDIO
    TITLE "Shock Box"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
  TRACK 05 AUDIO
    TITLE "Brand New Convertible Car"
    PERFORMER "Die Warzau"
    INDEX 00 03:26:58
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\05. Brand New Convertible Car.wav" WAVE
    INDEX 01 00:00:00
  TRACK 06 AUDIO
    TITLE "Burning"
    PERFORMER "Die Warzau"
    INDEX 00 06:25:07
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\06. Burning.wav" WAVE
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\07. All Cut Up.wav" WAVE
  TRACK 07 AUDIO
    TITLE "All Cut Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\08. Coming Down (Live).wav" WAVE
  TRACK 08 AUDIO
    TITLE "Coming Down (Live)"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\09. My Pretty Little Girlfriend.wav" WAVE
  TRACK 09 AUDIO
    TITLE "My Pretty Little Girlfriend"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\10. Red All Over.wav" WAVE
  TRACK 10 AUDIO
    TITLE "Red All Over"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\11. Pig City.wav" WAVE
  TRACK 11 AUDIO
    TITLE "Pig City"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\12. Dying in Paradise.wav" WAVE
  TRACK 12 AUDIO
    TITLE "Dying in Paradise"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\13. Suck It Up.wav" WAVE
  TRACK 13 AUDIO
    TITLE "Suck It Up"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
FILE "Die Warzau\1991 - Big Electric Metal Bass Face\14. Head.wav" WAVE
  TRACK 14 AUDIO
    TITLE "Head"
    PERFORMER "Die Warzau"
    INDEX 01 00:00:00
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2010-05-21 18:44:20
I found a CD in my collection where CUE Ripper cannot detect pre-gaps. What I do?


how did you do it? 
for me makes: 01.00 - (HTOA)

CUEripper rip:
Code: [Select]
REM ACCURATERIPID 0025fbfa-0205f0ea-ec0edf12
REM DISCID EC0EDF12
REM COMMENT "ExactAudioCopy v0.99pb4"
REM DATE 2002
PERFORMER "Buzzcocks"
TITLE "Ever Fallen in Love? Buzzcocks Finest"
CATALOG 0724385623820
FILE "01.00 - (HTOA).flac" WAVE
  TRACK 01 AUDIO
    TITLE "I Don't Mind"
    PERFORMER "Buzzcocks"
    INDEX 00 00:00:00
FILE "01 - I Don't Mind.flac" WAVE
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Whatever Happened to...?"
    PERFORMER "Buzzcocks"
    INDEX 00 02:19:28
.
.


EAC rip:
Code: [Select]
REM GENRE Punk
REM DATE 1997
REM DISCID EC0EDF12
REM COMMENT "ExactAudioCopy v0.99pb5"
PERFORMER "Buzzcocks"
TITLE "Ever Fallen In Love? - BUZZCOCKS FINEST"
FILE "01 - I Don't Mind.wav" WAVE
  TRACK 01 AUDIO
    TITLE "I Don't Mind"
    PERFORMER "Buzzcocks"
    PREGAP 00:00:32
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Whatever Happened To?"
    PERFORMER "Buzzcocks"
    INDEX 00 02:19:28
FILE "02 - Whatever Happened To .wav" WAVE
.
.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2010-05-21 20:19:38
I found a CD in my collection where CUE Ripper cannot detect pre-gaps. What I do?


how did you do it? 
for me makes: 01.00 - (HTOA)


LoL

PreserveHTOA=0
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marooned on 2010-05-22 02:02:54
Me not. Check the path. I have the following in my registry and it works:

[HKEY_CLASSES_ROOT\Folder\shell\cue tools]
"" = "Browse with CUETools"

[HKEY_CLASSES_ROOT\Folder\shell\cue tools\command]
"" = "C:\Work\cuetoolsnet\bin\Release\CUETools.exe" "%1"


Thank you for the reply.  I figured it out, but your post led me to a little digging through the registry.  It turns out that cuetools wasn't properly registered.  It was pointing to an obsolete .exe.  Just in case this happens to anyone else make sure that cuetools is  pointing to the right .exe location at the following registry key HKEY_CLASSES_ROOT\Applications\CUETools.exe\shell\open\command
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: esux on 2010-05-22 16:57:46
Still no multi-core support?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-22 17:49:55
If you are expecting multicore support in fb2k style, no, and i don't intend to implement it.

It's a bad idea to write several files in parallel. It's bad for your HDD and performance gains are too small.
It also doesn't help when using one-file disc images.

If you want fast compression, use FlaCuda, which uses many CPU cores and GPU. Assuming you have a compatible GPU, of course.
If you don't, then use libFlake, which is about twice as fast as standard FLAC when using similar compression ratios.
And try using lower compression levels like libFlake -3, extra 1% of used disc space won't kill you.
Also recent versions of CUETools do use at least two cores, with separate decoding thread.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-22 18:20:45
I found a CD in my collection where CUE Ripper cannot detect pre-gaps. What I do?

Are you sure this depends on the CD and not on the drive? Log files would be more informative than CUE sheets.
When using EAC-style log, CUERipper writes 'Gaps not detected' when it fails to detect gaps.
I didn't see it fail on the drives and CDs that i have, so if it fails for you, would be nice to know
is there any pattern to it - is it a certain drive or a certain CD that causes it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-22 22:10:33
CUETools 2.0.8 and 2.0.9 are not working for me under mono.

~/smb/CUETools_2.0.9$ mono ArCueDotNet.exe /tmp/Estatic\ Fear\ -\ Somnium\ Obmutum.flac.cue
Error: Access to the path "/tmp/orbit-root" is denied.

For some reason it needs to scan every file in that directory....

~/smb/CUETools_2.0.9$ mono ArCueDotNet.exe /tmp/arcue/Estatic\ Fear\ -\ A\ Sombre\ Dance.flac.cue
Error: Array index is out of range.

Works for me on centos 5 with mono 2.6.4:
It does scan every file in the directory, it has to, in order to locate audio files, logs, images etc properly.
It shouldn't however crash if there are files it cannot access...  Was this folder orbit-root somehow special (nfs or something)?

Code: [Select]
[gchudov@centos ct209]$ mkdir ~/ps/111
[gchudov@centos ct209]$ chmod 000 ~/ps/111
[gchudov@centos ct209]$ ll ~/ps/111
ls: /home/gchudov/ps/111: Permission denied
[gchudov@centos ct209]$  mono ~/ct209/ArCueDotNet.exe ~/ps/*.cue
[CUETools log; Date: 5/23/2010 1:03:33 AM; Version: 2.0.9]
[AccurateRip ID: 0001ff7c-0006d070-2003dd03] found.


I also couldn't reproduce "Array index is out of range" error. Can it be specific for this album image?

I found only one mono-specific problem so far: Error: An exception was thrown by the type initializer for System.Drawing.GDIPlus
ArCueDotNet tried to read cover art, and failed probably because some image-related libraries were missing.
So i modified ArCueDotNet to ignore cover art which it doesn't need anyway.

I also found out that published 2.0.9 version has 'plugins' folder in lowercase, and CUETools/ArCueDotNet expects "Plugins" folder which is not the same on unix, so i had to manually rename it to get FLAC support.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: esux on 2010-05-23 16:12:23
If you are expecting multicore support in fb2k style, no, and i don't intend to implement it.

It's a bad idea to write several files in parallel. It's bad for your HDD and performance gains are too small.
It also doesn't help when using one-file disc images.

If you want fast compression, use FlaCuda, which uses many CPU cores and GPU. Assuming you have a compatible GPU, of course.
If you don't, then use libFlake, which is about twice as fast as standard FLAC when using similar compression ratios.
And try using lower compression levels like libFlake -3, extra 1% of used disc space won't kill you.
Also recent versions of CUETools do use at least two cores, with separate decoding thread.


Thanks for the reply, I always felt foobar was much faster, but perhaps it was just my imagination then.

I have another question. The flake encoder cuetools use is a modified version? Is the flac one also modified or is it the same as the official?

Either way, thanks for taking the time to reply and for writing such a useful program.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-23 17:38:31
libFlake is very loosely based on flake. I kept the name mostly as a sign of respect for Justin Ruggles' work, which has been very useful in studying FLAC.
libFLAC is built from unmodified official libFLAC 1.2.1 sources.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-05-24 10:59:10
I have a feature proposal for CUETools' filename corrector...

CUE sheet cleanup. Like stripping replaygain comments from cue sheets (fb2k adds them), adding ARTIST to every TRACK (fb2k removes them)... and so on. Could this be done using a CT script?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-05-24 13:15:49
I already thought about asking about features like this, the problem is that if you start asking for stuff like this, cuetools will soon need additionnal developpers as Greg only has two hands ... the only thing I still don't do with cuetools are playback & ripping & cue tagging. If it goes on, Andree, Spoon & Peter will soon need a job in Canada too  I'm teasing but cuetools has definitely swallowed several use of F2K for me (specially the Converter). Cuetools eats cats for breakfast !

Edit:
Fandango:
Personnal tip:
If you want to strip replaygain info from all your cuesheet use Seeker (http://www.veign.com/application.php?appid=104), make it search for "replaygain" in .cue, then load the .cue it found in F2K & remove the replaygain information. It is not automatic, but overall it is still quite quick. Much more quicker than searching manually. [I use this method to identify pre-emphasised CD too, just search for "FLAGS PRE" in .cue]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2010-05-24 18:13:33
Hey, if CUE Tools added replaygain tags also, it would really be the only application I'd still need...
 

I think the real issue for Gregory apart from not having enough time would be to keep the user interface still usable when adding more features.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: koawmfot on 2010-05-24 19:02:49
i have a couple of feature requests too but would first like to thank you for such a fantastic application.

maybe this was covered already but support for XLD log files would be the icing on the cake for me.  they appear to be standard and similar enough to EAC logs i can't see this being more than a simple adjustment.

second - if the disc is not found in AR, could it still write the AR crc's to the cuetool's log file just so they are logged?  i know it puts them in a tag, but it writes a log file anyway and any extra info in the log couldn't hurt.

one other thing would be a cancel button on the log choice page but that is not a true functionality request.

again, thanks for such a great little app that i find more uses for daily.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2010-05-25 12:05:37
Every time I start CUEtools 2.0.9 it writes in log panel that "CUEtools 2.0.4 is out!"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-25 15:22:32
This might be caused by configuration files being unwritable.
You can try to delete [AppData\Roaming\CUE Tools\]settings.txt and/or motd.txt.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 2010-05-25 16:23:47
I removed motd.txt and the message disappeared. Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Teknojnky on 2010-05-25 21:40:31
Hi, thank you for your efforts and excellent tool.

Not sure if this has been asked before, but I was wondering there is any chance for a color coded or filterable log window?

Something that makes it easier to visually distinguish beween the various results for us old people.   

Thanks for your consideration.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: neovibe on 2010-05-26 10:50:20
Hi there... after a few weeks, finally tested a sync to iphone 3gs of an alac file compressed by cuetools and I can confirm it works fine and I can seek within a track unlike before.

can you tell me what was wrong? can I code a few hundred albums in alac with cue tools without need to worry?

thanks again, cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-05-26 12:11:20
Now that I updated to 2.0.9, I received an "Out of Memory" exception when analyzing a 387 MB .zip.wv file... 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Roger7 on 2010-05-27 12:22:12
Hi

I have a Metropolis press (MET 239): Das Ich - "Anti'Christ".
I tried to rip the CD on different drives (TEAC CD-W540E, Plextor Premium2) with dbpoweramp and EAC but I always got Inaccurate (confidence 4) ripping.
But I always got the same CRC. CueTools says:
Code: [Select]
[CUETools log; Date: 2010-05-27 12:20:18; Version: 2.0.9]
[CTDB TOCID: YCx9vQUvldjqE.8l_wlh3dnjQ2E-] disk not present in database.
[AccurateRip ID: 00194fed-00e27749-9c10aa0b] found.
Track   [ CRC    ] Status
01     [e34f473b] (0/4) No match
02     [f5983562] (0/4) No match
03     [88fee0a7] (0/4) No match
04     [cfff0385] (0/4) No match
05     [55d86a29] (0/4) No match
06     [c63226af] (0/4) No match
07     [aa3a87c9] (0/4) No match
08     [d435e7d0] (0/4) No match
09     [5c88e4e9] (0/4) No match
10     [79a67243] (0/4) No match
11     [4ce2c0ab] (0/4) No match
Offsetted by 144:
01     [9b73595b] (4/4) Accurately ripped
02     [db55adc2] (4/4) Accurately ripped
03     [87eedc77] (4/4) Accurately ripped
04     [a0d235d5] (4/4) Accurately ripped
05     [96987699] (4/4) Accurately ripped
06     [138021cf] (4/4) Accurately ripped
07     [db8821a9] (4/4) Accurately ripped
08     [e5e90080] (4/4) Accurately ripped
09     [cbe3eed9] (4/4) Accurately ripped
10     [3ec87e03] (4/4) Accurately ripped
11     [d4ac8fdb] (4/4) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--  100,0 [844ABFD6] [0A8F8B63]          
01  100,0 [53C1B802] [7FA85CEA]          
02  100,0 [A251E9E1] [BC416242]          
03  100,0 [363CF8AC] [D9636AB5]          
04  100,0 [17F30689] [DBDE4478]          
05   99,9 [713F13A3] [28240373]          
06  100,0 [0992F620] [4423AFC7]          
07  100,0 [E0B1AC64] [EE44239A]          
08  100,0 [5D593840] [93F19CB7]          
09  100,0 [BF26E81F] [E38F48B9]          
10  100,0 [6D21A7EB] [3FCE8931]          
11  100,0 [526D3857] [C7CB2E41]


Does it mean I have a different pressing that nobody else submitted ?
Should I encode this using cuetools and offset 144 to get perfect rip?
I tried to use EAC with reading offser set = drive offset + 144 and the rip was accurate (when checked by cuetools)
Thanks

Roger7
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-27 12:26:38
You've got a different pressing. There's no need to 'fix' it.

Besides, if you get the same CRC on different drives, that means your rip is accurate even if AccurateRip would say otherwise.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Roger7 on 2010-05-27 14:08:00
Thanks very much. Cuetools it's a great piece of software.
Just for sure:

Code: [Select]
[CUETools log; Date: 2010-05-27 14:48:22; Version: 2.0.9]
[CTDB TOCID: Og8vEUssnB3CIQ802m00TPiL3Ko-] disk not present in database.
[AccurateRip ID: 00101da3-00806aa1-8d09c30a] found.
Track   [ CRC    ] Status
01     [baa199b3] (00/15) No match
02     [19bb0231] (00/15) No match
03     [508cd71c] (00/15) No match
04     [6283a48e] (00/15) No match
05     [b0ded9ea] (00/15) No match
06     [db236186] (00/15) No match
07     [26fd7d32] (00/15) No match
08     [a569a33a] (00/15) No match
09     [e6b75f0d] (00/14) No match
10     [abf11bed] (00/15) No match
Offsetted by 1524:
01     [2c9e41cf] (10/15) Accurately ripped
02     [918cec3d] (10/15) Accurately ripped
03     [a9679338] (10/15) Accurately ripped
04     [80f446b6] (10/15) Accurately ripped
05     [6e484cfe] (10/15) Accurately ripped
06     [0dc75bb6] (10/15) Accurately ripped
07     [32b9834e] (10/15) Accurately ripped
08     [5d7c5f76] (10/15) Accurately ripped
09     [614acf95] (09/14) Accurately ripped
10     [351fbd61] (10/15) Accurately ripped
Offsetted by 2414:
01     [51f4ff5d] (05/15) Accurately ripped
02     [c50be0c3] (05/15) Accurately ripped
03     [f881dac6] (05/15) Accurately ripped
04     [8d0500ca] (05/15) Accurately ripped
05     [93527b08] (05/15) Accurately ripped
06     [453896ce] (05/15) Accurately ripped
07     [f056afdc] (05/15) Accurately ripped
08     [6431fb14] (05/15) Accurately ripped
09     [0f57acd9] (05/14) Accurately ripped
10     [ab333e9b] (05/15) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   99,9 [D9A06DBB] [AE6C854D]          
01   97,8 [FA2F84EB] [0140072C]          
02   97,8 [3F39F052] [722DBBCB]          
03   99,9 [8B53FA28] [F7E2710C]          
04   97,8 [858A3672] [BC85C6E4]          
05   97,8 [9CC12575] [5F37F7D9]          
06   97,8 [53A21829] [3B3909DE]          
07   97,8 [7E5D364F] [43D78B2F]          
08   97,8 [AEB600C2] [A2313C67]          
09   97,8 [78E474B5] [99FADD12]          
10   97,8 [3FAF56D9] [2326C5DE]


Does it mean there are at least 3 different pressings and I have one that nobody submitted ?

And question about flac - what encoder should I use for flac encoding: libFLAC, FlaCuda, libFlake, flake ?
What are the differences ?

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-27 15:36:26
Quote
Does it mean there are at least 3 different pressings and I have one that nobody submitted ?

Yes. Popular CDs sometimes have dozens of pressings.

Quote
And question about flac - what encoder should I use for flac encoding: libFLAC, FlaCuda, libFlake, flake ?

http://www.cuetools.net/doku.php/cuetools:...ders_comparison (http://www.cuetools.net/doku.php/cuetools:cuetools_flac_encoders_comparison)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Est on 2010-05-28 17:14:43
Can't add md5 checksum in wavpack (2.0.9) help please.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Roger7 on 2010-05-28 21:55:13
Yes. Popular CDs sometimes have dozens of pressings.


I ripped Tricky - "Knowle West Boy" on two drives (one on laptop - Sony DVD-ROM, one on my PC Teac CD-W540E) using dbpoweramp.
All rips are  Accurately ripped (cuetools or dbpoweramp).
All rips have the same accuraterip confidence on all tracks and all AccurateRip CRCs match on all tracks.
All file CRCs match except the one on last track - but AccurateRip is OK on both rips of that last track.
If I binary compare two waves there is a small difference in the very end of the tracks.
EAC WAV compare says: different samples position 0:03:47.0777- 0:03:47.093 and total length of file is 0:03:47.0933.
The difference is that the Teac's file has all zeros (00) and Sony's has sometime zeros (00) and sometimes FF in this fragment of track.
Sony has reading offset +6
Teac has reading offset +686
When I rip with another drive - Samsung DVDRW (SH-S223L) that has the same reading offset (+6) as Sony then I get the same CRC as Sony.
All 3 drives have Reading into Lead-in or Lead-out unchecked in dbpoweramp

So my question:
1. Which drive should I trust ?
2. I think the difference is because of different reading offsets ?
3. Should I use the drive that can read into Lead-in or Lead-out ?

Teac:
Code: [Select]
dBpoweramp Release 13.5 Digital Audio Extraction Log from 28 maja 2010 7:45

Drive & Settings
----------------

Ripping with drive 'G:   [TEAC     - CD-W540E        ]',  Drive offset: 686,  Overread Lead-in/out: No
AccurateRip: Active,  Using C2: No,  Cache: 149 KB,  FUA Cache Invalidate: No
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Ultra::  Vary Drive Speed: No,  Min Passes: 1,  Max Passes: 6,  Finish After Clean Passes: 2
Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 34

Encoder: FLAC -compression-level-5
DSP Effects / Actions: -dspeffect1="ReplayGain=-albummode={qt}0{qt}"

Extraction Log
--------------

Track 1:  Ripped LBA 0 to 16088 (3:34) in 0:19. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\01 - Puppy Toy.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 5200701B     AccurateRip CRC: 9562D7E8     [DiscID: 013-00157f19-00d88ab7-b80ac80d-1]

Track 2:  Ripped LBA 16088 to 33441 (3:51) in 0:17. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\02 - Bacative.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 35E1655E     AccurateRip CRC: 1F22335A     [DiscID: 013-00157f19-00d88ab7-b80ac80d-2]

Track 3:  Ripped LBA 33441 to 44610 (2:28) in 0:09. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\03 - Joseph.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: CBE11D6F     AccurateRip CRC: 461FC379     [DiscID: 013-00157f19-00d88ab7-b80ac80d-3]

Track 4:  Ripped LBA 44610 to 58109 (2:59) in 0:11. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\04 - Veronika.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 0E67E937     AccurateRip CRC: 14ECFA76     [DiscID: 013-00157f19-00d88ab7-b80ac80d-4]

Track 5:  Ripped LBA 58109 to 71880 (3:03) in 0:11. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\05 - C'mon Baby.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: E4146EFE     AccurateRip CRC: B498A85F     [DiscID: 013-00157f19-00d88ab7-b80ac80d-5]

Track 6:  Ripped LBA 71880 to 83839 (2:39) in 0:08. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\06 - Council Estate.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: DB193508     AccurateRip CRC: 52EB5B0C     [DiscID: 013-00157f19-00d88ab7-b80ac80d-6]

Track 7:  Ripped LBA 83839 to 106888 (5:07) in 0:17. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\07 - Past Mistake.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: E82F3F3F     AccurateRip CRC: 784FBD12     [DiscID: 013-00157f19-00d88ab7-b80ac80d-7]

Track 8:  Ripped LBA 106888 to 124792 (3:58) in 0:12. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\08 - Coalition.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: 539903DF     AccurateRip CRC: 73030D29     [DiscID: 013-00157f19-00d88ab7-b80ac80d-8]

Track 9:  Ripped LBA 124792 to 141710 (3:45) in 0:11. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\09 - Cross to Bear.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 10AEFE14     AccurateRip CRC: DD367EC5     [DiscID: 013-00157f19-00d88ab7-b80ac80d-9]

Track 10:  Ripped LBA 141710 to 156895 (3:22) in 0:09. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\10 - Slow.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 79712B03     AccurateRip CRC: 0FD7DA7F     [DiscID: 013-00157f19-00d88ab7-b80ac80d-10]

Track 11:  Ripped LBA 156895 to 173565 (3:42) in 0:10. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\11 - Baligaga.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: 7EDD6438     AccurateRip CRC: EDBF97FE     [DiscID: 013-00157f19-00d88ab7-b80ac80d-11]

Track 12:  Ripped LBA 173565 to 189972 (3:38) in 0:10. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\12 - Far Away.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: 44210919     AccurateRip CRC: 1483A466     [DiscID: 013-00157f19-00d88ab7-b80ac80d-12]

Track 13:  Ripped LBA 189972 to 207004 (3:47) in 0:10. Filename: D:\Images\FLAC\Tricky\Knowle West Boy (2008)\13 - School Gates.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: D612F9E6     AccurateRip CRC: D971FEFA     [DiscID: 013-00157f19-00d88ab7-b80ac80d-13]

--------------

13 Tracks Ripped Accurately


Sony:

Code: [Select]
dBpoweramp Release 13.5 Digital Audio Extraction Log from 28 maja 2010 10:39

Drive & Settings
----------------

Ripping with drive 'D:   [SONY     - DVD-ROM DDU810A ]',  Drive offset: 6,  Overread Lead-in/out: No
AccurateRip: Active,  Using C2: No,  Cache: None,  FUA Cache Invalidate: No
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 34

Encoder: FLAC -compression-level-5
DSP Effects / Actions: -dspeffect1="ReplayGain=-albummode={qt}0{qt}"

Extraction Log
--------------

Track 1:  Ripped LBA 0 to 16088 (3:34) in 0:21. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\01 - Puppy Toy.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 5200701B     AccurateRip CRC: 9562D7E8     [DiscID: 013-00157f19-00d88ab7-b80ac80d-1]

Track 2:  Ripped LBA 16088 to 33441 (3:51) in 0:45. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\02 - Bacative.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1 & 2]
  CRC32: 35E1655E     AccurateRip CRC: 1F22335A     [DiscID: 013-00157f19-00d88ab7-b80ac80d-2]

Track 3:  Ripped LBA 33441 to 44610 (2:28) in 0:15. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\03 - Joseph.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: CBE11D6F     AccurateRip CRC: 461FC379     [DiscID: 013-00157f19-00d88ab7-b80ac80d-3]

Track 4:  Ripped LBA 44610 to 58109 (2:59) in 0:14. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\04 - Veronika.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 0E67E937     AccurateRip CRC: 14ECFA76     [DiscID: 013-00157f19-00d88ab7-b80ac80d-4]

Track 5:  Ripped LBA 58109 to 71880 (3:03) in 0:13. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\05 - C'mon Baby.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: E4146EFE     AccurateRip CRC: B498A85F     [DiscID: 013-00157f19-00d88ab7-b80ac80d-5]

Track 6:  Ripped LBA 71880 to 83839 (2:39) in 0:11. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\06 - Council Estate.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: DB193508     AccurateRip CRC: 52EB5B0C     [DiscID: 013-00157f19-00d88ab7-b80ac80d-6]

Track 7:  Ripped LBA 83839 to 106888 (5:07) in 0:21. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\07 - Past Mistake.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: E82F3F3F     AccurateRip CRC: 784FBD12     [DiscID: 013-00157f19-00d88ab7-b80ac80d-7]

Track 8:  Ripped LBA 106888 to 124792 (3:58) in 0:34. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\08 - Coalition.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1 & 2]
  CRC32: 539903DF     AccurateRip CRC: 73030D29     [DiscID: 013-00157f19-00d88ab7-b80ac80d-8]

Track 9:  Ripped LBA 124792 to 141710 (3:45) in 0:13. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\09 - Cross to Bear.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 10AEFE14     AccurateRip CRC: DD367EC5     [DiscID: 013-00157f19-00d88ab7-b80ac80d-9]

Track 10:  Ripped LBA 141710 to 156895 (3:22) in 0:11. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\10 - Slow.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 79712B03     AccurateRip CRC: 0FD7DA7F     [DiscID: 013-00157f19-00d88ab7-b80ac80d-10]

Track 11:  Ripped LBA 156895 to 173565 (3:42) in 0:12. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\11 - Baligaga.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: 7EDD6438     AccurateRip CRC: EDBF97FE     [DiscID: 013-00157f19-00d88ab7-b80ac80d-11]

Track 12:  Ripped LBA 173565 to 189972 (3:38) in 0:12. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\12 - Far Away.flac
  AccurateRip: Accurate (confidence 41)     [Pass 1]
  CRC32: 44210919     AccurateRip CRC: 1483A466     [DiscID: 013-00157f19-00d88ab7-b80ac80d-12]

Track 13:  Ripped LBA 189972 to 207004 (3:47) in 0:12. Filename: C:\Roger\Temp\!rip\Tricky\Knowle West Boy (2008)\13 - School Gates.flac
  AccurateRip: Accurate (confidence 42)     [Pass 1]
  CRC32: 32C6944E     AccurateRip CRC: D971FEFA     [DiscID: 013-00157f19-00d88ab7-b80ac80d-13]

--------------

13 Tracks Ripped Accurately


Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-30 03:24:57
Can't add md5 checksum in wavpack (2.0.9) help please.

Oops. Sorry. Will fix this ASAP.

So my question:
1. Which drive should I trust ?
2. I think the difference is because of different reading offsets ?
3. Should I use the drive that can read into Lead-in or Lead-out ?

Yes, the drive that cannot overread into Lead-out and positive offset will loose the last few samples and they will be replaced by zeroes. Number of lost samples equals drive offset.
So for best results you might want to use drive with small offset or better yet drive that can overread into leadout.
But keep in mind, that 6 samples is not very much audio, about 0.1 millisecond, and that audio in that part of CD is usually very close to silence anyway, so i wouldn't worry very much about it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Saxo on 2010-05-30 10:50:42
CUERipper request:

Just a nitpick:
With CUETools I have a perfect control on what tags I allow in the flac file (I personally dislike metadata in flac files and rather have a .cue and .log as separate files so I uncheck all tags-related buttons). There's no option for this in CUERipper, it automatically embeds .cue and .logs in the flac, that I have to manually remove. Could you please add an option for CUERipper not to tag flac files? I understand that the strength of CUERipper, especially when compared to EAC is its simplicity and that it works as it should out of the box (with EAC you have to read literally pages of documentation for it to be configured in a half-decent fashion). So, maybe that a single checkbox (all or nothing, without CUETools' granularity) would be a good compromise.


CUETools and UTF-8:

It seems that CUETools doesn't recognize UTF-8 encoded files that doesn't have a BOM. Notepad doesn't have this problem, but WordPad does. Is it a limitation of the .NET framework?


Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2010-05-30 15:39:29
A month ago I  discovered a pregap 32,33,37 script in cuetools and used it since. After upgrading to 2.0.9. it didn't work anymore so I deleted all settings and opened 2.0.9. again.
But now the whole script was gone.
So I tried downgrading to 2.0.8, 2.0.7, 2.0.6 etc. (deleting settings in between) but now I can't find the script in any of them (I must be getting crazy  )
What has happened to the script and can it be put back in again?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-30 19:32:02
This script was never built-in, i posted it here a while ago. It requires a small change to work with 2.0.9:
Code: [Select]
if (processor.ArVerify.ExceptionStatus == WebExceptionStatus.Success)
  return processor.Go();
if (processor.PreGapLength != 0)
  return processor.WriteReport();;
foreach (uint gap in new uint[3] {32, 33, 37})
{
  processor.PreGapLength = gap;
  processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
  if (processor.ArVerify.ExceptionStatus == WebExceptionStatus.Success)
    return processor.Go();
}
return processor.WriteReport();
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2010-05-30 20:28:47
This script was never built-in, i posted it here a while ago. It requires a small change to work with 2.0.9:


So I'm not getting crazy, just forgetful 

Thanks again for the script !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-05-30 22:21:15
Wow Custom Proxy implemented!
Awesome stuff again Gregory !

-When set to encode mode, with no audio output, using the same file extension as the source files, (flac in this case,
& using [%directoryname%\]%filename%-new[%unique%].cue, you will get an error saying
"Exception: Source and destination audio files path cannot be the same".

(obviously If you use a new dir path like [%directoryname%\]new[%unique%]\%filename%.cue, all is well).
Thanks !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Roger7 on 2010-05-30 22:43:02
Yes, the drive that cannot overread into Lead-out and positive offset will loose the last few samples and they will be replaced by zeroes. Number of lost samples equals drive offset.
So for best results you might want to use drive with small offset or better yet drive that can overread into leadout.
But keep in mind, that 6 samples is not very much audio, about 0.1 millisecond, and that audio in that part of CD is usually very close to silence anyway, so i wouldn't worry very much about it.

OK, so why are AR CRC accurate ? How is it count ?

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-30 22:53:17
2940 last samples are ignored by AR.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-05-31 00:36:13
I Think I found another bug,

-When Encoding, unticking the Embed Image, image still gets  embedded.[checked again & again -  bug still happens]
-The image embedded gets resized even if the Resize threshold is set higher,(to 6000 here, so it can be avoided). [could not get it to happen again.]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-05-31 02:59:43
Is there away to enable the "pressing #X" in the reports?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-05-31 03:04:31
FWIW, #X has no definitive meaning in terms of the pressing.

Go back over this thread as this question has been asked already.

http://www.hydrogenaudio.org/forums/index....st&p=643854 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=643854)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-05-31 19:01:39
-When Encoding, unticking the Embed Image, image still gets  embedded.[checked again & again -  bug still happens]

It seems that when "Copy album art tags" is enabled, image gets embedded even if it comes from a file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2010-06-01 00:28:44
Been using CUETools for verifying purposes for quite a time now. Really a nice and time-saving app, so thanks everybody envolved.
Now I'm experiencing a tricky issue since the last update (i.e 2.0.9). All profiles work fine, I can do all my usual tasks, but can't
switch between different profiles. I can jump from "default" to any other, but next switch always outputs an "unhandled exception...
blah-blah-blah... error generating XML document"
. I may ignore and go on but... just pisses me off! (Oops, sorry!  )

Previous version (2.0.4a to me) worked just perfect. My system: XP SP3, NET Framework 2.0/3.0/3.5, Visual C++ 2005/2008. All updated.
What should I do? Will keep on using old version in the meantime.

Best regards and thx in advance... for all!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Surfi on 2010-06-01 12:32:39
::

CUERipper doesn't overread (into leadout) with my Plextor PX-760. Is this intended?
What do I have to do to get an output like "Queen [1976] A Night At The Opera.cue"?


Greetings, Surf ...

::
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-01 20:55:30
I don't have a drive capable of overreading, so i couldn't implement it yet. I know it's important for some users, but it will take some time.

Try the following template:
%music%\%artist%[ - '['%year%']'] - %album%.cue
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Surfi on 2010-06-01 21:06:29
I don't have a drive capable of overreading, so i couldn't implement it yet. I know it's important for some users, but it will take some time.
::

No problem, keep up the good work. Thanks for the great program!

::
Try the following template:
%music%\%artist%[ - '['%year%']'] - %album%.cue
::

It works. Thank you very much.

::
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bit4bit on 2010-06-02 16:35:32
I'm archiving all my CDs as single file flac archives. I am using EAC to rip the CDs as wav and CUETools for further processing, and usually everything works well. But I've got some CDs which cannot be ripped accurately by EAC. When testing with CueTools it reports these tracks as "No match but offset". Here is one example from the CD "The Diary of Alicia Keys".

Code: [Select]
[CUETools log; Date: 02.06.2010 11:43:43; Version: 2.0.9]
CD-Extra data track length 06:29:57.
[CTDB TOCID: iU4E1m24Moh64VNA4F0gdiW4nDY-] disk not present in database.
[AccurateRip ID: 00204005-017582d7-e40fae10] found.
Track  [ CRC    ] Status
 01    [3b4075b2] (63/63) No match but offset
 02    [0e3a61e9] (53/53) No match but offset
 03    [a825faf6] (59/59) No match but offset
 04    [ea23f312] (63/65) No match but offset
 05    [6caa3fae] (51/51) No match but offset
 06    [ceaef50f] (62/62) No match but offset
 07    [c7847c85] (64/64) No match but offset
 08    [48e16522] (60/60) No match but offset
 09    [9a0338cf] (59/59) No match but offset
 10    [274b1d53] (64/64) No match but offset
 11    [f5caba62] (58/58) No match but offset
 12    [473e8077] (68/68) No match but offset
 13    [073b8142] (64/64) No match but offset
 14    [078d46d7] (58/58) No match but offset
 15    [c3b240e9] (58/60) No match but offset
Offsetted by -6:
 01    [8b86f3b2] (00/63) No match
 02    [0def6ee7] (00/53) No match
 03    [899baafc] (00/59) No match
 04    [b5b56c6d] (02/65) No match but offset
 05    [63ba64c7] (00/51) No match
 06    [923771f6] (00/62) No match
 07    [e826ae81] (00/64) No match
 08    [812b4e72] (00/60) No match
 09    [47027c6d] (00/59) No match
 10    [e0ece63e] (00/64) No match
 11    [2ac98e95] (00/58) No match
 12    [ed8c154e] (00/68) No match
 13    [a412f21a] (00/64) No match
 14    [a5d8d624] (00/58) No match
 15    [c5e4e5b8] (02/60) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [20320805] [4B10FC0D]         
 01  99,9 [1FFFB333] [6B393E9F]         
 02  99,9 [6B81A9D3] [8066306B]         
 03  100,0 [7FD0EC70] [83FBFD85]         
 04  99,9 [CD645887] [374E49A5]         
 05  96,8 [270F1320] [DFB78AE3]         
 06  99,9 [A6B08FB7] [2FE16BBA]         
 07  99,9 [E4276564] [FE8F03E0]         
 08  99,9 [FCE4F7D3] [294E461B]         
 09  99,9 [256BA34D] [CCBA33A6]         
 10  100,0 [49D67666] [04280299]         
 11  99,9 [7E260F85] [7A69795F]         
 12  89,0 [13499D76] [8D5DFD33]         
 13  99,9 [AF6998AF] [06AA9E27]         
 14  99,9 [330D8400] [AB49CF81]         
 15  99,9 [2999782F] [F5E465BA]         
Does this mean, that the tracks are ripped without error but with the wrong offset? Can CUETools fix this error?
Or is this an inaccurate rip without any chance for a repair?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-02 21:17:02
This seems to be an inaccurate rip without any chance for a repair - errors in each track.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bit4bit on 2010-06-03 11:17:48
Gregory, thank you for your fast reply. I was always wondering how other 50 - 65 people were able to make an accurate rip. This leads me to another question. Is it in any way possible to retrieve information about the CD-Drives these people used from the AccurateRip database?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: maiolina on 2010-06-03 22:34:25
Hi, and thanks for this very useful application!
I've read in some posts that there's a script that checks automatically for the "usual" pregap times (32, 37 ms etc), where can I find it?
Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-03 22:46:58
This leads me to another question. Is it in any way possible to retrieve information about the CD-Drives these people used from the AccurateRip database?

Nope. If you don't have such problems with other CDs, most probably it's just a bad CD.

I've read in some posts that there's a script that checks automatically for the "usual" pregap times (32, 37 ms etc), where can I find it?

Ahem, [a href='index.php?act=findpost&pid=707559']one page earlier[/a]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: maiolina on 2010-06-03 23:18:31
Ooops you're right, I've surrender some pages before...
How do I apply the custom script to CT 2.0.9?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-03 23:50:32
Go to advanced settings (by clicking the gray cog-wheel at the top), proceed to the Scripts tab, click on any script, press Insert. Enter the name of new script, paste the code on the right, and check the 'Verify' option for this script.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: maiolina on 2010-06-04 00:31:01
Thanks, now it's time to test it!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: krafty on 2010-06-04 21:17:52
Gregory, this is what I get in Ubuntu 10.04 when I run CUETools and press "Settings" button....
Am I missing a package or is it a bug?

Code: [Select]
user@orion-desktop:~/win32/CUETools_2.0.6$ mono CUETools.exe
System.NullReferenceException: Object reference not set to an instance of an object
  at JDP.frmSettings.encodersBindingSource_CurrentItemChanged (System.Object sender, System.EventArgs e) [0x00000]
  at System.Windows.Forms.BindingSource.OnCurrentItemChanged (System.EventArgs e) [0x00000]
  at System.Windows.Forms.BindingSource.<ConnectCurrencyManager>m__5 (System.Object o, System.EventArgs args) [0x00000]
  at System.Windows.Forms.CurrencyManager.OnCurrentChanged (System.EventArgs e) [0x00000]
  at System.Windows.Forms.CurrencyManager.ChangeRecordState (Int32 newPosition, Boolean validating, Boolean endCurrentEdit, Boolean firePositionChanged, Boolean pullData) [0x00000]
  at System.Windows.Forms.CurrencyManager.UpdateIsBinding () [0x00000]
  at System.Windows.Forms.CurrencyManager.ListChangedHandler (System.Object sender, System.ComponentModel.ListChangedEventArgs e) [0x00000]
  at System.Windows.Forms.BindingSource.OnListChanged (System.ComponentModel.ListChangedEventArgs e) [0x00000]
  at System.Windows.Forms.BindingSource.ResetBindings (Boolean metadataChanged) [0x00000]
  at System.Windows.Forms.BindingSource.SetList (IList l) [0x00000]
  at System.Windows.Forms.BindingSource.ResetList () [0x00000]
  at System.Windows.Forms.BindingSource.OnParentCurrencyManagerChanged (System.Object sender, System.EventArgs args) [0x00000]
  at System.Windows.Forms.CurrencyManager.OnMetaDataChanged (System.EventArgs e) [0x00000]
  at System.Windows.Forms.CurrencyManager.ListChangedHandler (System.Object sender, System.ComponentModel.ListChangedEventArgs e) [0x00000]
  at (wrapper delegate-invoke) System.ComponentModel.ListChangedEventHandler:invoke_void__this___object_ListChangedEventArgs (object,System.ComponentModel.ListChangedEventArgs)
  at System.Windows.Forms.BindingSource.OnListChanged (System.ComponentModel.ListChangedEventArgs e) [0x00000]
  at System.Windows.Forms.BindingSource.ResetBindings (Boolean metadataChanged) [0x00000]
  at System.Windows.Forms.BindingSource.SetList (IList l) [0x00000]
  at System.Windows.Forms.BindingSource.ResetList () [0x00000]
  at System.Windows.Forms.BindingSource.set_DataSource (System.Object value) [0x00000]
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.BindingSource:set_DataSource (object)
  at JDP.frmSettings.frmSettings_Load (System.Object sender, System.EventArgs e) [0x00000]
  at System.Windows.Forms.Form.OnLoad (System.EventArgs e) [0x00000]
  at System.Windows.Forms.Form.OnLoadInternal (System.EventArgs e) [0x00000]
System.ObjectDisposedException: The object was used after being disposed.
  at System.Windows.Forms.Control.CreateHandle () [0x00000]
  at System.Windows.Forms.Form.CreateHandle () [0x00000]
  at System.Windows.Forms.Control.get_Handle () [0x00000]
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:get_Handle ()
  at System.Windows.Forms.Application.RunLoop (Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x00000]
  at System.Windows.Forms.Form.ShowDialog (IWin32Window owner) [0x00000]
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Form:ShowDialog (System.Windows.Forms.IWin32Window)
  at JDP.frmCUETools.toolStripButtonSettings_Click (System.Object sender, System.EventArgs e) [0x00000]
  at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs e) [0x00000]
  at System.Windows.Forms.ToolStripButton.OnClick (System.EventArgs e) [0x00000]
  at System.Windows.Forms.ToolStripItem.HandleClick (System.EventArgs e) [0x00000]
  at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs e, ToolStripItemEventType met) [0x00000]
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem:FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType)
  at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs mea) [0x00000]
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x00000]
user@orion-desktop:~/win32/CUETools_2.0.6$
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-06-09 02:52:21
-When Encoding, unticking the Embed Image, image still gets  embedded.[checked again & again -  bug still happens]

It seems that when "Copy album art tags" is enabled, image gets embedded even if it comes from a file.


Thanks for verifying this.
I have another question, when using CueRipper, it ignores the proxy settings I use in CueTools,
Am I missing something, or did I just submit another feature request  ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2010-06-11 16:28:04
In the fake EAC log when using burst mode, are there really two passes (test and copy)? It's been my experience with a scratched disc that the disc is only ripped once in burst mode, because I am getting matching CRCs in CUERipper where it seems nearly impossible to get matching CRCs.

If you are really only making one pass, please make the log indicate such. Otherwise, it's INCREDIBLY misleading. If I rip a disc that's not in the AR or CT databases, and there are no errors in the log, I would come to the conclusion that the rip was good because the log indicates matching CRCs.

Here are two rips of the same track.


Code: [Select]
Track 18

     Peak level 85.1 %
     Track quality 100.0 %
     Test CRC A70CFB1B
     Copy CRC A70CFB1B
     Cannot be verified as accurate (confidence 2)  [63C66920], AccurateRip returned [0DB83FED]
     Copy OK



Code: [Select]
Track 18

     Suspicious position 0:00:00 - 0:00:04
     Suspicious position 0:00:07 - 0:00:24
     Suspicious position 0:00:35 - 0:01:07
     Suspicious position 0:01:09
     Suspicious position 0:01:14 - 0:01:33
     Suspicious position 0:02:13 - 0:02:24
     Suspicious position 0:02:26 - 0:02:36

     Peak level 99.8 %
     Track quality 100.0 %
     Test CRC 5B1D0D44
     Copy CRC 5B1D0D44
     Cannot be verified as accurate (confidence 2)  [BEDCF086], AccurateRip returned [0DB83FED]
     Copy OK


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wooops on 2010-06-13 23:05:34
One minor question, since 2.0.9 how can you display the summary and the verification log? If I select Multibrowser or drag´n drop mode it only shows the summary i.e. "AR: offset 681, rip accurate (7/7), CTDB: disk not present in database.", while in folder mode or without browser it only displays the log. :S

btw been using CT for some time and works great, thank you a lot!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2010-06-17 15:49:16
I noticed a weird behavior on some of my rips... I verified & submitted my library today and some lines in the log caught my eye:
Quote
B:\Music\hack//G.U\[Album] hack//G.U. Game OST I  Disc #1.flac: AR: offset -499, rip not accurate (2/2), CTDB: disk not present in database, z6E00y3ZcDQWhRDTr0EoMeovtQU- has been uploaded.
B:\Music\hack//G.U\[Album] hack//G.U. Game OST I  Disc #2.flac: AR: rip not accurate (2/2), CTDB: disk not present in database, TJbX55eCSO6YmSH5qOBoNsjOMk8- has been uploaded.
B:\Music\Kajiura Yuki\[Album] Kajiura Yuki - Noir - Blanc dans Noir II.flac: HDCD detected, AR: offset 30, rip not accurate (0/5), CTDB: disk not present in database, will not submit.
What I wonder is, why does it submit anything to the CTDB if the rip is not accurate? Also, the Noir CD is a simple audio CD and not a HDCD (what's that, anyway oO)

Also, it seems like simply checking if the disk exists on AR isn't a good idea. CueTools found some of the single flac tracks lying around my HDD in AR and submitted them as albums to CTDB ._.
Maybe you should add a length check to it? I doubt there are singles out that are <10 mins long.
Scratch that, i just looked at the log again and it seems CUETools was smart enough to treat them as albums and not single tracks. That's great
edit2: There is one problem though, looks like it checks the %album% tag only. I have some rips that have the same %album% tag and only differ by %discnumber% tags. Cuetools treated this album as 1 CD...

One more thing, could you pleas add a "Yes to all"/"No to all" buttons? When one verifies the whole library, it's really annoying to sit there an confirm you want to overwrite the logs.
Also, why is CUETools still writing "Disk not found in CTDB" in the log if it just submitted the album to the DB itself?

edit: just ran verify a second time to test if the 2 "not accurate" rips were really submitted:
Code: [Select]
B:\Music\hack//G.U\[Album] hack//G.U. Game OST I  Disc #1.flac: CUEToolsDB: verified OK, confidence 2.
B:\Music\hack//G.U\[Album] hack//G.U. Game OST I  Disc #2.flac: CUEToolsDB: verified OK, confidence 2.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Admiral Oggbar on 2010-06-21 19:40:43
Also, the Noir CD is a simple audio CD and not a HDCD (what's that, anyway oO)

HDCDs are simple audio CDs with (allegedly) higher quality due to tricks that allow a 20-bit depth in the standard 16-bit audio. If CUETools says it's HDCD, it most certainly is, and you'll see in the options the ability to decode to 20-bits.

One more thing, could you pleas add a "Yes to all"/"No to all" buttons? When one verifies the whole library, it's really annoying to sit there an confirm you want to overwrite the logs.

x1000!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2010-06-22 22:23:31
Quote
If CUETools says it's HDCD, it most certainly is

It doesn't really make sense for it to be a HDCD when the first CD isn't; the first CD contains the songs with vocals, the second only contains some of the songs w/o vocals + some tracks that didn't make it to the soundtrack.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2010-06-25 22:23:37
Can't seem to edit my last post for some reason...

I just re-viewed the log cuetools created and it did detect the first cd as hdcd too. I must have been really tired when I checked it the last time.

edit: I have a question about offset correction: is it safe to do it? Does it affect something audible or is it simply for having a cue that is closer to the original?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-26 05:19:07
I have a question about offset correction: is it safe to do it? Does it affect something audible or is it simply for having a cue that is closer to the original?

It is relatively safe, that's exactly what EAC does when your drive has non-zero offset and is not capable of overreading (most drives aren't). You can loose only as many samples as the offset, i.e. few milliseconds at one of the edges of the disc. However, there's not much point in doing this. EAC does it to be able to use it's primitive AccurateRip implementation, but CUETools can verify non-offset-corrected rips, so there's really no point. Unless you want to burn a CD-R and want it to be non-distinguishable from the original CD, and you didn't use offset correction when you ripped it, or you want to use a burning program that is incapable of offset-correction for write-offset.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2010-06-26 11:06:00
I see. What about my post on the previous page? Any idea why CueTools submits rips to the CTDB despite saying itself that they are not accurate?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-26 11:28:46
Presumably that's because there's a slight discrepancy in two ways CUETools determines if the rip is accurate.
If it was really inaccurate, the message would read 'rip not accurate, (0/2)', not (2/2).
I wasn't able to reproduce such case yet, but my guess is that each track is accurate, but not within the same offset.
Such rip shouldn't have been submitted, i will correct this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zetto on 2010-06-28 20:07:11
When I try to convert or verify via commandline I get this:

Processing XYZ.cue:
Error: Object reference not set to an instance of an object.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-06-28 22:45:34
The profile/settings system is still buggy and not fixed/redesigned (check my notes (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=679211) from January (perhaps the 11th point in the codebox list)), that's what most probably is causing the error.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zetto on 2010-06-28 23:31:11
thanks, that helped.

I get another error when verifying a rip with a data track as track 1.

When I verify with the cue I get:

Code: [Select]
Exception: Invalid track number.


Well, that's most likely because track 01 (the data track) isn't referenced in the cue. it starts with track 02.

But why do I get the following error:

When I verify with the audio files as input I get this:

Code: [Select]
Exception: crc.Combine length cannot be negative
Parameter name: len2


It runs through until the very end until that error pops up.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-29 05:20:38
Are you sure you are using the latest version (2.0.9)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zetto on 2010-06-29 09:36:08
yes I'm using 2.0.9
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-06-29 09:57:38
Ok, confirmed the bug with CDs that have data track in the beginning. Working on it. Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zetto on 2010-06-29 10:29:14
no prob. Thanks for the support!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2010-06-29 18:04:42
Hey Greg,

Code: [Select]
[CUETools log; Date: 29.06.2010 18:54:15; Version: 2.0.9]
[CTDB TOCID: ddtaskdPyyRBfBOJeWntybiAIDI-] found.
        [ CTDBID ] Status
        [438774b6] (12/12) Has pregap length 00:00:32
[AccurateRip ID: 00091292-002c06df-350b9705] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
--   99,6 [904E2FF5] [8161D8C5]          
01   99,6 [5EF4CF04] [CDEB36BC]          
02   99,6 [9665242D] [B0708154]          
03   99,5 [E383ED8C] [2A6F4929]          
04   99,6 [604AC167] [BF52E65F]          
05   99,6 [63648CD3] [24AA0426]


CUETools has detected that this rip normally has a pregap length of 00:00:32 even though I have no CUE sheet for this anymore.
But it doesn't clearly show that the rip is accurate. Also the AccurateRip ID seems to be calculated wrong!

I know that the right ID here is 00091352-002c097e-390b9705.
So if I add this as ACCURATERIPID tag to my files, everything is fine, even though there still is no pregap information!

Code: [Select]
[CUETools log; Date: 29.06.2010 18:59:21; Version: 2.0.9]
Using preserved id, actual id is 00091292-002c06df-350b9705.
[CTDB TOCID: ddtaskdPyyRBfBOJeWntybiAIDI-] found.
        [ CTDBID ] Status
        [438774b6] (12/12) Has pregap length 00:00:32
[AccurateRip ID: 00091352-002c097e-390b9705] found.
Track   [ CRC    ] Status
01     [7302cda8] (15/15) Accurately ripped
02     [7cb47b43] (15/15) Accurately ripped
03     [ffe08507] (15/15) Accurately ripped
04     [c7acc227] (14/14) Accurately ripped
05     [86577805] (15/15) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   99,6 [904E2FF5] [8161D8C5]          
01   99,6 [5EF4CF04] [CDEB36BC]          
02   99,6 [9665242D] [B0708154]          
03   99,5 [E383ED8C] [2A6F4929]          
04   99,6 [604AC167] [BF52E65F]          
05   99,6 [63648CD3] [24AA0426]


Personally I don't care much about gaps and pregaps, I only want accurate audio tracks but I still wanted to report this.
Not sure if this is a bug!?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2010-07-01 17:04:26
Hi,

Thanks for  the tool, it's VERY useful.

I would like a more detailed CUETools log:

1. instead of: [AccurateRip ID: 0022e065-018b7275-da0ed20f] found. -> [AccurateRip ID: 0022e065-018b7275-da0ed20f]: rip accurate (70/70) or rip not accurate
2. if the cue file is invalid or corrupt put in the log the same message that is output as on the screen. (e.g.  unable to locate the audio files.)
3. if the cue file is invalid, get past it and try to check the files as there was no cue at all.
4. if there is no cue: put that info into the log.
5. add the info from the CUETools DB page:
Quote
TOC ID   GkJJuhhILfFRrKunU6io4JUkLB0-
CRC32 ID   BC01CDF1
Musicbrainz ID   AXEyRA3OelAz7XpuJINN4eoZqJo- (-)
CDDB/Freedb ID   
6608A909
AccurateRip ID   000b4a46-00549711-6608a909
Artist   YMCK
Title   YMCK SONGBOOK -songs before 8bit-

6. Any other information you can think of would be more than welcomed.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-03 18:39:16
Hi Greg,
I found a sub-optimal CT behavior, I wouldn't call this a bug, but for the first time I tried to "encode/fix offset/highest confidence" on an enhanced CD with no log but for which I know that it is in CTDB with the good data track length. I would have expected Cuetools to grab the data track length from CTDB & then "fix" the offset, instead of that CT didn't even checked CTDB & returned not present in AR database ;( ... so it seems that depending on the chosen options the automatic grabbing of the data track length from CTDB doesn't always work. I know the box for CTDB is only there for the "verify" option, but in this case it would be usefull for the "encode" option.

Not a priority, but still I wanted to point this out.
See Ya Next Bug
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dalza on 2010-07-04 11:52:50
Hello.  I am new to ripping cds  and just discoverd CUETools.  The reason why I am using this program is to verify that files ripped to FLAC before I started using DBPoweramp are Accurately Ripped.  If I understand correctly, this is possible with CUETools. 

I downloaded the program and verified a cd already ripped to FLAC.  Here are the settings I used to Verify:

.  My end goal is to have a “perfect” FLAC file.  Any recommended settings would be greatly appreciated.


My second question is about interpreting the CUETools log file that was generated using the above settings.  Here it is.  My question is pretty simple, What does all this garble mean?  Sorry for being obtuse, but I don’t get it.

I would appreciate any and all help from forum members who are familiar with how CUETools works.  Thanks in advance.
David (CUETools log below)


[CUETools log; Date: 03/07/2010 18:26:49; Version: 2.0.9]
[CTDB TOCID: 95rD6_gaJlQ702Uih.7d4KcJWQI-] disk not present in database.
[AccurateRip ID: 000f830c-0087f90e-9e095e0b] found.
Track  [ CRC    ] Status
01    [ff3f3996] (10/83) Accurately ripped
02    [e4793440] (10/84) Accurately ripped
03    [b8efbe8d] (10/83) Accurately ripped
04    [c01b811d] (10/83) Accurately ripped
05    [43181ce7] (10/86) Accurately ripped
06    [de75205e] (10/82) Accurately ripped
07    [9e56391d] (10/83) Accurately ripped
08    [7febe9c3] (10/81) Accurately ripped
09    [18f874a2] (10/82) Accurately ripped
10    [6579da7a] (10/81) Accurately ripped
11    [3d350037] (09/78) Accurately ripped
Offsetted by -139:
01    [225989a9] (02/83) Accurately ripped
02    [834c65a5] (04/84) Accurately ripped
03    [b1bd302b] (03/83) Accurately ripped
04    [63ef226e] (03/83) Accurately ripped
05    [3d01e358] (04/86) Accurately ripped
06    [5df4efbd] (03/82) Accurately ripped
07    [f54a9f42] (03/83) Accurately ripped
08    [8f9ed44f] (03/81) Accurately ripped
09    [36c516f8] (03/82) Accurately ripped
10    [5c43ae7c] (03/81) Accurately ripped
11    [1b372a50] (03/78) Accurately ripped
Offsetted by -3:
01    [659c0e34] (04/83) Accurately ripped
02    [4d0f8f1b] (04/84) Accurately ripped
03    [8aced1ad] (04/83) Accurately ripped
04    [0f277056] (04/83) Accurately ripped
05    [e508e640] (04/86) Accurately ripped
06    [b34392f3] (04/82) Accurately ripped
07    [2959386c] (04/83) Accurately ripped
08    [85c9192f] (04/81) Accurately ripped
09    [9a88d7e8] (04/82) Accurately ripped
10    [7d38394c] (04/81) Accurately ripped
11    [2806a41a] (04/78) Accurately ripped
Offsetted by 32:
01    [8063f331] (03/83) Accurately ripped
02    [dee9cb4b] (03/84) Accurately ripped
03    [f9edf282] (03/83) Accurately ripped
04    [ca46debd] (03/83) Accurately ripped
05    [2e650e87] (03/86) Accurately ripped
06    [1b280735] (03/82) Accurately ripped
07    [d3f73cfa] (03/83) Accurately ripped
08    [415f4543] (03/81) Accurately ripped
09    [5d9efc62] (03/82) Accurately ripped
10    [12e091ba] (03/81) Accurately ripped
11    [07addc46] (03/78) Accurately ripped
Offsetted by 106:
01    [de390f34] (03/83) Accurately ripped
02    [fa7ece3c] (03/84) Accurately ripped
03    [bc8518f7] (03/83) Accurately ripped
04    [81cb273f] (03/83) Accurately ripped
05    [3e86fd49] (03/86) Accurately ripped
06    [8dfb43e1] (03/82) Accurately ripped
07    [6ea03332] (03/83) Accurately ripped
08    [b0ba08db] (03/81) Accurately ripped
09    [8c60164e] (03/82) Accurately ripped
10    [73de197e] (03/81) Accurately ripped
11    [faa3d39b] (03/78) Accurately ripped
Offsetted by 210:
01    [6c37ed60] (05/83) Accurately ripped
02    [134e1fc0] (05/84) Accurately ripped
03    [4cef6c4b] (05/83) Accurately ripped
04    [22d81787] (05/83) Accurately ripped
05    [fb410e91] (05/86) Accurately ripped
06    [954a1ac6] (05/82) Accurately ripped
07    [636725a1] (05/83) Accurately ripped
08    [e570f23b] (05/81) Accurately ripped
09    [ab7d4f7e] (05/82) Accurately ripped
10    [e76bed0e] (05/81) Accurately ripped
11    [16692efd] (05/78) Accurately ripped
Offsetted by 322:
01    [2e086f82] (06/83) Accurately ripped
02    [3d8b21c7] (06/84) Accurately ripped
03    [b9a06a54] (06/83) Accurately ripped
04    [466fdf37] (06/83) Accurately ripped
05    [b2ce5c41] (06/86) Accurately ripped
06    [166751bf] (06/82) Accurately ripped
07    [77696594] (06/83) Accurately ripped
08    [0a84b27b] (06/81) Accurately ripped
09    [1bc42a9e] (06/82) Accurately ripped
10    [c6536e6e] (05/81) Accurately ripped
11    [da306141] (05/78) Accurately ripped
Offsetted by 404:
01    [885064e3] (03/83) Accurately ripped
02    [5e841d80] (03/84) Accurately ripped
03    [591f1a99] (03/83) Accurately ripped
04    [807eff21] (03/83) Accurately ripped
05    [bdc3876b] (03/86) Accurately ripped
06    [14576ada] (03/82) Accurately ripped
07    [ff07d415] (03/83) Accurately ripped
08    [6a3c4cf3] (03/81) Accurately ripped
09    [9baee67a] (03/82) Accurately ripped
10    [92aaa402] (03/81) Accurately ripped
11    [b33833d4] (03/78) Accurately ripped
Offsetted by 583:
01    [4fcdd808] (47/83) Accurately ripped
02    [372608ff] (46/84) Accurately ripped
03    [8a83be4f] (46/83) Accurately ripped
04    [696192d8] (46/83) Accurately ripped
05    [a9f9ef02] (48/86) Accurately ripped
06    [8dc076c7] (45/82) Accurately ripped
07    [10757bc0] (46/83) Accurately ripped
08    [0c5994c7] (44/81) Accurately ripped
09    [13b26dd4] (45/82) Accurately ripped
10    [b4a13510] (45/81) Accurately ripped
11    [c2ecdaf4] (43/78) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--  97,7 [17F26069] [E1009768]         
01  97,7 [892C8A27] [5691D5C3]         
02  97,7 [F0EFA722] [5D1F4396]         
03  97,7 [28B74073] [0EF429AF]         
04  97,7 [4EA94D9A] [F4E2F878]         
05  97,7 [F35D9F86] [8826FF3A]         
06  70,3 [E2ED01A2] [0507905C]         
07  97,7 [82FFCD3C] [4C2F1FE9]         
08  97,7 [3FC39BF3] [E72698BA]         
09  97,7 [DCB3F1A2] [2358F3F3]         
10  97,7 [351C6CEF] [71CE4EA8]         
11  97,7 [AACB5D37] [2BC520A4]   
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-04 12:26:18
dalza:
Quote
1) Under “Verify”, If I select “Write AccurateRip tags” what does this do?
2) Should I check the “Encode if verified” box? What does this do?
3) What does “fix offset “ do?


Pretty much all the options you asked does what it says it does, so you need to do some serious reading, anyway it's a sunny sunday here & I am in a good mood, so here is some short answers:
1, I don't use this option but I think it must write a specific tag with the confidence level, maybe for use with F2K.

Edit: Both 2 & 3 are parameters for "Encode/If verified" & "Encode/Fix Offset" options on the main CT screen.

2, Well just as it says: it encodes only if the rip is verified accurate, you can rise or lower the requirement.
3, Well just as it says: it "fixes the offset" either to the nearest offset (no matter confidence) (tick) or to the highest confidence (no matter offset) (untick), this is usefull if you didn't set the offset while ripping for "nearest" or usefull if you want shorter/easier to read logs for "highest" ... anyway both are useless if you only care for audio quality. Those are mostly .accurip display options.

Quote
What does all this garble mean?

It means your rip is perfect. (Tip: use Codebox to post long logs)

Have a nice sunny Sunday. See Ya.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zetto on 2010-07-04 14:25:29
"Write AccurateRip tags" does just what is sais. Writing AccurateRip tags to your checked files.

Following tags are written:

ACCURATERIPCOUNT
ACCURATERIPCOUNTALLOFFSETS
ACCURATERIPCRC
ACCURATERIPDISCID
ACCURATERIPID
ACCURATERIPTOTAL
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2010-07-04 21:51:36
Hey Greg,

I'm back with one more issue with this wonderful tool:

When multiple discs are ripped to tracks and stored in the same folder, CUETools won't recognize anything above disc 5.
When there is also 6 discs or more, all the tracks are shown under disc 5.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2010-07-04 23:53:47
This might be a bug, or maybe I misunderstood the script.
If I verify multiple Albums with [%directoryname%\]%filename%-new[%unique%].cue,
if a *.accurip exists inside the folder, CueTools will prompt to overwrite.

-Did I wrongly assume the %unique% variable will prevent the prompt?

Also, If I use [%directoryname%\]%filename%-new[%unique%].cue, & choose ENCODE, with no audio output,
I get a "source & destination path cannot be the same" error.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dalza on 2010-07-05 09:28:38
Thank you Sauvage78 & Zetto for your quick responses (I'm glad the weather was nice yesterday ) .

Although I think I’m starting to understand this program a bit better, I am still confused by how to set the option to achieve the results I want (and yes, I did already read through most of this topic’s 44 pages!).

Let’s say I start with a FLAC files on my computer; for example the Fleetwood Mac Album.

My goal is to verify that the rip I have is “perfect” (accurate).  So, I run the “Verify” function and get the log report posted above.  Now, I have to interpret the results. This is where I am having some difficulties.

The first set of info in the log is:

Track [ CRC ] Status
01 [ff3f3996] (10/83) Accurately ripped
02 [e4793440] (10/84) Accurately ripped
03 [b8efbe8d] (10/83) Accurately ripped
04 [c01b811d] (10/83) Accurately ripped
05 [43181ce7] (10/86) Accurately ripped
06 [de75205e] (10/82) Accurately ripped
07 [9e56391d] (10/83) Accurately ripped
08 [7febe9c3] (10/81) Accurately ripped
09 [18f874a2] (10/82) Accurately ripped
10 [6579da7a] (10/81) Accurately ripped
11 [3d350037] (09/78) Accurately ripped

1) This first set results verifies that the FLAC files I tested are accurate, right? 
2) So, for Track 1 for example, it is accurately ripped with a confidence level of 10.  Is this correct?
3) If this is the case, than I have nothing more to do, correct?

Where I start to get confused is with all of the subsequent sets of info about “Offsetting”.  If the first set of information is Accurately Ripped, then for my purposes, all of the other information is extraneous… I don’t have to worry about it.  Is this correct?

I hope my questions are clear.  At this point, my only goal is to verify that the FLAC files I have on my computer are bit perfect (accurate).   

One more question in anticipation: If I find that a rip I have is not accurate, can CUETools fix it?

Thank you all for your help.

Sincerely,
David
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-05 10:09:32
dalza:
1, Yes
2, Yes
3, Yes, nothing.
4, Yes, because "a match is a match" & because all tracks are always accurate on each single offset, all the pack of results are pressings that only differs by the offset. In your case, you can "fix" offset from pressing X to pressing Y & still have a perfect match, it's not always the case. In fact in your case you can consider that the confidence level is much higher than 10, because all the pressings are nearly identical. The log looks very long but in fact it is a simple case.
5, If the rip is in CTDB maybe. Note that, because databases are not perfect, a non-accurate result doesn't necessarily means that the rip is bad. AR works more on positive results than on negative results, if it matches with a confidence 2 you can say that it is almost certainly perfect (with the exception of a few samples in the very beginning/end). If it doesn't then you can only make guesses/probability with the overall information provided by all pressings. Sometimes the probability of a scratch is obviously high, sometimes you can't tell.

See Ya.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dalza on 2010-07-05 10:52:41
Sauvage78, thanks again for your help.

In fact, when you say "pressings" do you mean "cd-drive offsets"?  Sorry if my question is naive, but I'm still a bit confused.

In any case, thanks for answering all of my questions.  I can now get to work verifying the rips I already have and then deciding which disks I have to re-rip/re-buy.

And by the way, thank you to everyone who maintains/improves this great program!

Sincerely,
David
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-05 11:17:03
By "pressing" I mean physical edition of the CD, those can differ just by the offset due to write offset small shift when "re-pressing" (your case) or more than just by the offset, if the content was edited in some way before being "re-pressed".

In your case, pressings & offsets are "the same", because all pressings only differs by the offset, which means one pressing=one write offset.

I am not speaking of your personnal CD-drive offset, you fixed it while ripping because you match with offset 0.

The machine used to press CD, just like your CD-drive does have different write offsets too, these are the offset you see in the .accurip. For exemple, pressing X with offset +123 may be produced in Europe with a machine with a write offset +123 while pressing Y with offset +321 may be produced in America with a machine with write offset +321 (using the same master).

This is a very theoric simplification, you'll soon realize that there is often more pressings/offsets than possible markets which means compagnies selling CD don't care about the offset, they obviously just re-press when there is a commercial demand, creating lots of pressings that only differs by the offset over the years.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Revy on 2010-07-05 17:49:05
OK, I might be dumb but I tried everything I can imagine, and CUETOOLS doesn't work with me, when I try to open it says "CUETOOLS HAS STOPPED WORKING". Nothing more.

I use windows 7 64bits, I tried to download .net framework 2.0 but it seems windows 7 already includes that (installer says it).
I have installed framework 4.0 too. C++ 2005/2008/2010 were already installed before I downloaded cuetools.

If it helps the only cuetools I can seem to open is the experimental one (2.0.2a)

EDIT2: Tried to use the debug function in VS2010 and... Exception has been thrown by the target of an invocation. {"Font 'Courier New' does not support style 'Regular'."} I didn't have courier new installed somehow and the program crashes because of that. Reinstalled the font and problem solved. Might want to work around that font demand so it won't crash
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zarggg on 2010-07-06 02:23:33
Courier New should be present in every Windows install everywhere, unless it was removed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: patmcg on 2010-07-08 06:55:36
Sorry, but this is really bothering me. Is there anyway the listings in the Folder Browser can be sorted alphabetically. Right now all the folders are totally random. I'm running 2.0.9.

thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zetto on 2010-07-09 14:28:46
Gregory, do you plan adding CRC comparison support for XLD rips/logs? Currently only works with EAC logs as far as I know.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Native_Soulja on 2010-07-10 03:28:07
Does this CueTools 1.9.5 program work with EAC?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dalza on 2010-07-10 11:54:34
Hello all,

I'm back with another question regarding the CUETools log.  Can someone tell me what "No match but offset" means in this context (Track 05)?  Is it accurately ripped?  Thanks for all of your help.

Sincerely,
David


Code: [Select]
[CUETools log; Date: 10/07/2010 12:49:16; Version: 2.0.9]
CD-Extra data track length 04:22:11.
[CTDB TOCID: 3mES5USX6AGJehYoh7T5Kfd2Ssc-] found.
        [ CTDBID ] Status
        [720aa726] (309/309) Differs in 292 samples @22:35:49,22:52:04-22:52:05,23:04:11-23:04:12,23:06:46-23:06:47
[AccurateRip ID: 00157488-00b8d3b2-9a0dc30c] found.
Track   [ CRC    ] Status
01     [a38e2507] (200/330) Accurately ripped
02     [bd900319] (200/332) Accurately ripped
03     [b161a1b5] (200/330) Accurately ripped
04     [14aa242f] (200/331) Accurately ripped
05     [ced55a29] (200/330) No match but offset
06     [80d04dda] (200/332) Accurately ripped
07     [0c426ddf] (200/330) Accurately ripped
08     [0481ddad] (200/331) Accurately ripped
09     [4b90657c] (198/325) Accurately ripped
10     [bf5d19d6] (200/331) Accurately ripped
11     [a724b90c] (192/321) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Recusant on 2010-07-10 13:02:13
Hiya, i'm just trying out CueRipper. Works well, but it would be nice to see an 'options' button in the ripper program (not just in CueTools).

Also - for some reason, it stores the files with underscore instead of dash, e.g.: "01. Commander Tom _ Are Am Eye"

I can't find a setting that might change that. It's odd because i expect to see underscores instead of spaces, but not as well as.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hacker1208cb on 2010-07-10 15:12:55
Sorry, but this is really bothering me. Is there anyway the listings in the Folder Browser can be sorted alphabetically. Right now all the folders are totally random. I'm running 2.0.9.

thanks.


This sounds like the bug I reported and offered a patch for back in October. ([a href='index.php?act=findpost&pid=660745']See the post here[/a])
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-10 16:31:46
dalza:
Code: [Select]
[ CTDBID ] Status
[720aa726] (309/309) Differs in 292 samples @22:35:49,22:52:04-22:52:05,23:04:11-23:04:12,23:06:46-23:06:47


seems scratched around playing time 22-23min for CTDB

Code: [Select]
05     [ced55a29] (200/330) No match but offset


seems scratched at track 5 for AR

... seems like you can fix it with CTDB, (otherwise CTDB would return either "not found", "no match" or "could not verify"), try encode/repair, then if it matches you corrected it.

Edit:
You can listen at min 22-23min & see if you ear a glitch ... then, if you ear a glitch, you can compare with your EAC log ... that is a rewarding bittersweet experience ... if you ear a glitch that EAC didn't reported despite "perfect settings" for the drive, I can tell ya that you will trust . accurip more than .log after that !!!

If earable, you can even re-listen to the glitch before & after fixing it ... to fully convince yourself.
The only problem with repair that you should be aware, is that it looks like  sometimes you can fix a perfect but not yet in database rip X with the data of perfect rip Y already in database. It's not a big issue, it's just up to the end user to decide if it's worth fixing with all the positive/negative hints privided by AR/CTDB/LOG & listening test. Personnaly, so far I always fixed unless there was 2 entry in CTDB, one matching/one differing but in this case the clash is obvious. Also fixing first & last tracks is also dubtious sometimes because of excluded samples: sometimes if it differs at the very beginnings/ends, you know you might only have partially fixed it, but it's all you can do. Anyway very short glitches shouldn't be earable at these locations (likely in the middle of silence) (... well I hope).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dalza on 2010-07-10 18:26:48
Sauvage78,

Thanks again for your detailed responses.  I don't have time now to sit down and test everything you suggested; I should have the time to play around tomorrow.  I'll let you know how it turns out.  Also, thanks for the explanation about pressings.


All the best,
David
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: osodeh on 2010-07-12 18:23:49
Is CUERipper in beta mode? Because I can't get it to work with proxy settings that I apparently have to enter in CUETools. I can get the proxy working w/ cuetools, but not cueripper, so none of the values are inputed rendering the program cumbersome to use.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-07-17 13:55:14
Hello:

A disk was ripped with EAC using ideal settings (Secure, accurate stream, defeat cache, no C2, offset correction 6, etc.). EAC log reports no errors. This is a portion of the EAC log for Track 3:

Quote
Track  3

    Filename E:\media\SILVIO2\Musica\Genesis\Genesis - Foxtrot (1972) [FLAC]\03 - Get 'Em Out by Friday.wav

    Pre-gap length  0:00:00.45

    Peak level 98.4 %
    Track quality 100.0 %
    Test CRC E2DFE6D2
    Copy CRC E2DFE6D2
    Cannot be verified as accurate (confidence 26)  [7948005D], AccurateRip returned [D71AE96E]
    Copy OK


I use CueTools to check rip against database, AccurateRip reports "No match but offset" for track 3. Here is the contents of the .accurip file:

Quote
[CUETools log; Date: 17/07/2010 8:40:05 AM; Version: 2.0.9]
[CTDB TOCID: .SYxP91kRf6.ipY7pUtp21PODp0-] disk not present in database.
[AccurateRip ID: 000a14a2-0036c476-3b0c0806] found.
Track  [ CRC    ] Status
01    [3cfffc33] (25/27) Accurately ripped
02    [82c6b7c0] (26/28) Accurately ripped
03    [7948005d] (26/28) No match but offset
04    [4d911a40] (26/28) Accurately ripped
05    [9f17c4d3] (26/28) Accurately ripped
06    [77ebd650] (26/28) Accurately ripped
Offsetted by -1157:
01    [e6f0797a] (02/27) No match but offset
02    [ba46bcf6] (02/28) No match but offset
03    [6663b554] (02/28) No match but offset
04    [19540bea] (02/28) No match but offset
05    [fd80f75d] (02/28) No match but offset
06    [e6aa25e7] (02/28) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
--  100.0 [67C29617] [F8810DA6]
01  99.0 [C4BFC969] [577F842C]  CRC32
02  90.5 [4DF8C633] [102914B6]  CRC32
03  98.4 [E2DFE6D2] [ACA4C6A9]  CRC32
04  100.0 [BE75E706] [882A5B84]  CRC32
05  100.0 [DDC2ECB5] [C5104D03]  CRC32
06  100.0 [ECCA4D0E] [AFE3F62A]  CRC32


So, EAC says rip is okay, but AccurateRip reports "No match but offset" for track 3.
What does this mean?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-17 16:45:54
fadsplat:
Quote
What does this mean?


... nothing special other than what you explained, either EAC is wrong & you have a scratch or EAC is right, there is no scratch & you have a third pressing that is not yet in AR. The probability is low but yes EAC log can be wrong sometimes, specially with bad settings for the drive. I noticed it dozen of times & I was sure that there was a scratch as I listened to the files & heard it ...

Listen to the file & judge yourself, many glitches cannot be heard anyway, so if the goal is to encode it lossy ... in the end it doesn't matter ... if the goal is to keep it lossless, then re-check later both AR & CTDB, maybe you'll be able to fix it with CTDB someday.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2010-07-18 10:34:44
Quote
.. nothing special other than what you explained, either EAC is wrong & you have a scratch or EAC is right, there is no scratch & you have a third pressing that is not yet in AR


EAC did not spot the error. Cuetools is reporting that 1 offset finding frame (out of 30,000) matches the data in AccurateRip (but there is an error somewhere in the other 29999 frames) - such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-07-18 11:33:21
Quote
.. nothing special other than what you explained, either EAC is wrong & you have a scratch or EAC is right, there is no scratch & you have a third pressing that is not yet in AR


EAC did not spot the error. Cuetools is reporting that 1 offset finding frame (out of 30,000) matches the data in AccurateRip (but there is an error somewhere in the other 29999 frames) - such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks.

sauvage78, spoon, thank you very much for your explanations. Do you know why EAC did not spot the error ? Is it because of the drive, EAC code or a combination of the two ? Cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-07-18 17:32:18
such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks

Can you please elaborate on this? Do you mean that the track is essentially accurate? Do you mean that the music has been captured correctly, but that there is just some insignificant technical error? I'd like to know more about what "No match but offset" means in such a context, as I occasionally see rips like that and wonder if such rips are okay or not.

To answer someone else's question, I save only FLAC lossless, and I listen to lossless through a good home stereo. So, I do want good rips.

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-07-18 18:23:13
I finally upgraded from 2.0.4a to 2.0.9 only to find more problems. ("clean" install, deleted old settings & program files)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-07-18 19:06:14
you have a scratch

Is this your universal lingo for saying the disc was ripped with an error?  It's getting quite annoying since errors can be caused by more than just scratches.  Wouldn't you rather choose words that decrease the chances that you are providing false information?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-07-18 19:19:13
Do you know why EAC did not spot the error ?
It came up the same way twice, so EAC assumed it is good.  EAC cannot detect errors that are consistent, especially if you aren't allowing it to use C2 pointers.  Unfortunately, if you were to use C2 pointers and EAC identified the error, re-reads would probably still produce the same bad results since C2 pointers aren't used during re-reads.

Is it because of the drive, EAC code or a combination of the two ? Cheers
Likely a combination of the drive and the disc and shortcomings with EAC when it comes to these situations.

such reporting is not really required as you can see that track 3 is from that data set "accurate (confidence 26) [7948005D]" because the confidence is the same for all the other tracks
Can you please elaborate on this?
Spoon is trying to tell you that there is no reason to doubt the result since all submissions to the database for your pressing of this disc by others are correct.

Do you mean that the track is essentially accurate? Do you mean that the music has been captured correctly, but that there is just some insignificant technical error?
No, he means that your rip of the track in question is in error.

I'd like to know more about what "No match but offset" means in such a context, as I occasionally see rips like that and wonder if such rips are okay or not.
As spoon told you, the offset match is just a matching hash for only one frame of audio data (588 samples).  This offset hash is included in the AR record so that people can use that particular disc to determine their drive's read offset.  It is completely useless when it comes to determining if your track was ripped accurately.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2010-07-18 19:35:09
Thanks a lot for the info greynol. So this is a generic problem: using a different ripping program with the same drive and CD would produce the same result ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-07-18 19:42:39
I wouldn't go so far as to say that, no.  You might actually get a different result by switching to burst mode, or changing EAC's secure mode options; you might even get an accurate rip this way.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-18 19:57:28
Quote
Is this your universal lingo for saying the disc has an error?

I'll try to say "error" next time the data differs...

Edit:
Also I must correct myself: because you fixed the offset while ripping & because the results in AR look consistent, it can hardly be a third pressing not yet in database. It's always possible but the chances are rather low: as far as I understund it would almost mean a rare exact re-pressing (same offset, 5/6 track matching) with error/difference on track 3. Not impossible but very unlikely. With confidence 26, you'd better bet on an error in your own rip as Spoon explained.

As I personnaly don't fix offset while ripping & fix later to "highest" in cuetools, I tend to always think that it can be a pressing not yet in database with a different offset when it doesn't match, because my own offset is always "floating". It's a kind of "Déformation professionnelle" (http://en.wikipedia.org/wiki/D%C3%A9formation_professionnelle) ... sorry for missleading you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-07-18 20:14:00
I reworded what I said after your quote to try to be more encompassing, since the error could be the result of a problem with the ripping program, the drive, or both.  IOW, it isn't always the disc's fault.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: edwardar on 2010-07-24 09:25:35
Thanks so much for such an amazingly useful tool!  I have a feature request:

Would it be possible to implement an test for a silent HTOA:

If a silent HTOA exists, then convert without creating HTOA file (using pregap in the cuesheet instead).
If the HTOA is non-silent, then create an HTOA file.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-07-27 00:50:03
I have a few requests/suggestions and questions regarding CUEripper:

* Could you implement a summary after each rip telling what CUEripper did? Did the rips comply with AR confidence? Did it submit a CTDB entry etc.
* ...also please add options for e.g. ejection of media. Currently I have no idea when it's finished (and want to move on to next disc)
* Custom path and file-formatting?
* Repair bad rips with existing CTDB-correction entrys (on the fly that is, or at least afterwards without using cuetools?)

You say that CTDB can be submitted even when AR doesn't exist. That's probably great if multiple CTDB entrys exists for the same disc. However, I own a bunch of rare discs which nobody would probably ever put up in the DB, so How do I ensure that my rip was as perfect as it can be and sit in the CTDB? Can I rip the same disc with different drives on the same PC (and same IP)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: didomh on 2010-07-28 12:42:07
Hi everybody, i have a probelm with  CUETools_2.0.9,

Yesterday he recognized the CD my drive, and naming songs and album name itself. Today, however, when I put the same disc he tells me that no connections, says "Title1, Title2" etc. What could be the problem, whether there was something in my computer?

Any ideas?

Thanks for help!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: OpTicaL on 2010-07-28 23:17:44
I'm a total n00b to CUETools. I've been reading the forums and CUETools seems to be the the splitter of choice when it comes to splitting a single FLAC album into separate tracks compared to Medieval CUE Splitter.

I am currently in drag'n drop mode and output has been grayed out. I want to save the tracks on my desktop but it's forcing me to use a template.

My other question is, after selecting FLAC for audio output what are the difference between libFLAC, FlaCuda, libFlake, and flake? Which is the best encoder to use?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Daffy on 2010-07-29 00:13:12
My other question is, after selecting FLAC for audio output what are the difference between libFLAC, FlaCuda, libFlake, and flake? Which is the best encoder to use?


Directly from the CUETools website:

CUETools FLAC Encoders Comparison (http://www.cuetools.net/doku.php/cuetools:cuetools_flac_encoders_comparison)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: OpTicaL on 2010-07-30 03:00:56
Directly from the CUETools website:

CUETools FLAC Encoders Comparison (http://www.cuetools.net/doku.php/cuetools:cuetools_flac_encoders_comparison)


Thanks, where can I find information that explains the functions in settings, for example under Gaps Handling, what is Gaps Appended + HTOA? and what are the settings for separating a single FLAC album into individual tracks?

Action is set to: Encode (this is the settings that confuses me the most, I'm not trying to "encode" anything, I just want to split the album into separate tracks)

Mode is set to: Tracks

Audio Output is set to: Lossless, flac, libFLAC

Will these settings split any album with a proper cue sheet into individual tracks?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-07-31 17:22:47
This is the accurip result from a rip:

Code: [Select]
[CUETools log; Date: 31/07/2010 11:09:19 AM; Version: 2.0.9]
[CTDB TOCID: ywGA0VEGplUQBvpiAqaZhRuK5FM-] disk not present in database.
[AccurateRip ID: 0023db0a-0182babe-ba11940e] found.
Track  [ CRC    ] Status
 01    [ada7bd94] (0/0) No match
 02    [2187068f] (0/0) No match
 03    [1c7bdcd6] (0/0) No match
 04    [45ddad7c] (0/0) No match
 05    [120153c9] (0/1) No match
 06    [962ab792] (0/1) No match
 07    [f9d004d4] (0/1) No match
 08    [cbaeb8a7] (0/1) No match
 09    [3387a182] (0/1) No match
 10    [402570c9] (0/1) No match
 11    [ebd2ef5b] (0/0) No match
 12    [fda743a9] (0/0) No match
 13    [b0448498] (0/1) No match
 14    [65cbe62d] (0/1) No match
Offsetted by 664:
 01    [23b09bfc] (0/0) No match
 02    [a8c84027] (0/0) No match
 03    [54fe11ae] (0/0) No match
 04    [f071096c] (0/0) No match
 05    [ebebacb1] (1/1) Accurately ripped
 06    [f975bc22] (1/1) Accurately ripped
 07    [812b435c] (1/1) Accurately ripped
 08    [49310417] (1/1) Accurately ripped
 09    [675d017a] (1/1) Accurately ripped
 10    [591052f9] (1/1) Accurately ripped
 11    [67191463] (0/0) No match
 12    [4aac27b1] (0/0) No match
 13    [4cc10158] (1/1) Accurately ripped
 14    [8b5b041b] (1/1) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98.1 [0369921D] [F11AB304]
 01  98.1 [9E02E5DB] [326EE1AA]
 02  94.2 [11D0F840] [871A3913]
 03  95.9 [C91A2A23] [2C56EA92]
 04  95.6 [3750EE7A] [82E55CDB]
 05  95.4 [4439B63A] [A0AE2395]
 06  95.4 [37A5E994] [A15EC1C7]
 07  95.7 [CDD32218] [CDC0F7DF]
 08  97.0 [B4DC74CF] [0BF56714]
 09  97.2 [D3E915D3] [36FABDE8]
 10  96.7 [FA06A049] [D47E58CB]
 11  97.3 [29030D07] [196EF2D6]
 12  96.3 [0C17EEF2] [D0205E7D]
 13  96.8 [A6A6FE36] [601D5B37]
 14  96.8 [01F4968F] [1262C656]

Does this mean the rip is definitely not accurate, or is it simply that this particular disk/pressing may not be in the AccurateRip database?

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-31 17:34:56
fadsplat:
Hi.
Not yet fully in AR database. Nothing bad to worry about so far.
See Ya.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-07-31 17:38:40
I see the term "no match" but I don't see the term "not accurate".

It is pretty clear that there is no data available for tracks 1-4, 11 and 12.  For the other tracks you got a match, so it should be readily obvious once you consider what X/Y means (X is the number of people who submitted that particular checksum out of Y total checksum submissions for that track), that the tracks without a match the result is inconclusive.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-07-31 17:42:00
CUETools is constantly giving me an array index out of bound exception when trying to process any cue file ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-31 17:54:46
Open the cue sheet with notepad & post it, from my experience this kind of things happens when:
1-INDEX 00 is frozen. (Not chronological order)
2-INDEX 00 is after the end of the whole CD range.
3-The cue was produced when splitting with "Medieval Cue Splitter".

It's pure speculation but the two first may be related to bad gap/index detection either due to CD protection or broken software/hardware.

Edit: If you can, post a CDImage type cue sheet, because I am only used to this displaying.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-07-31 17:58:49
It happens with all CUE files I have, it didn't earlier. 
Also, it happens before or after checking MusicBrainz, so I guess it's not related to the cue files at all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-31 18:02:40
Oh... I am of no help sorry ... I never used MusicBrainz. Sound weird.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-07-31 18:06:35
Indeed it does. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-07-31 22:53:47
Not yet fully in AR database. Nothing bad to worry about so far.

I see the term "no match" but I don't see the term "not accurate".

It is pretty clear that there is no data available for tracks 1-4, 11 and 12.  For the other tracks you got a match, so it should be readily obvious once you consider what X/Y means (X is the number of people who submitted that particular checksum out of Y total checksum submissions for that track), that the tracks without a match the result is inconclusive.


That's what I thought. And yet, the single line summary that appears in CueTools says:
Quote
Off White.cue: AR: offset 664, rip not accurate (0/1), CTDB: disk not present in database.

Why does CueTools say "not accurate", when examining the .accurip report suggests more that there is just not enough data yet and that this disk/pressing is not yet in the database?


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-07-31 23:40:48
fadsplat:
Quote
Why does CueTools say "not accurate"


Because Cuetools is a machine & because AR works more on positive matches than on negative missmatches, which means that AR is made to tell you if your rip is perfect or not. When it is not it doesn't tell you why. It just tell you that it doesn't match.

If CT/AR returns a perfect results then there is a near 100% probability that it is right.
If CT/AR returns a non perfect results, CT/AR make no assumption on the files & leaves the final verdict to the end user's judgement.

"rip not accurate" may be missleading at first. But it is right, the rip is "not accurate according to accuraterip database" which in your case means "not accurate yet because the database is incomplete".

Reading "rip not accurate" in a CT's log is not as definitive as reading "There were errors" in an EAC's secure log.

In fact reading CT/AR logs is the reverse of reading EAC secure logs:
- usually CT/AR logs are near 100% reliable when it tells you that there is no errors (all tracks matches) & not 100% reliable when something doesn't match (The database may be incomplete)
[Edit: Well AR is reliable but CT's conclusion is not)
- usually EAC secure logs are near 100% reliable when there is an error, but not 100% reliable when there is no error. (there can be unnoticed error, specially with bad settings for the drive)

The irony here is that some people read the exact opposite, they think an EAC secure log with no error is perfect & start whinning when CT/AR returns "rip not accurate".

"rip not accurate" in CT/AR doesn't necessary mean "rip inaccurate". Both are not synonymous in the context of CT/AR logs.

Cuetools cannot return a personnalized anwser for each rip. When the answer is not clear, it means that it can only give you hints that you have to interpret.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-07-31 23:58:11
Thank you. That explanation is very helpful.

I guess the the problem is the terminology that CueTools uses. When it says "rip not accurate", that is a clear statement that the rip is bad, and yet this statement may be wrong.

It would be better if CueTools reported something like "rip does not match" in such cases.


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: g725s on 2010-08-03 14:05:54
Does the latest download of CUETools typically include a Readme file that covers installation proceedure of the program?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-03 16:54:55
"rip not accurate" may be missleading at first. But it is right, the rip is "not accurate according to accuraterip database" which in your case means "not accurate yet because the database is incomplete".

It is not right nor are any of these interpretations that you're offering right.  It's also not "may be" misleading "at first," it is completely misleading, especially in the situation presented by fadsplat.

There is absolutely no reason whatsoever why the wording need be the way that it is.  Have a look at the messages presented in an EAC log regarding AR results if you have any doubts.

IMO, the rest of your answer was spot-on including the part about EAC's log only being "almost" perfect when it says there are errors.  It's quite possible for EAC to tell you there was an error even though the track was indeed ripped accurately.  This will usually happen when the most consistent data is accurate data but not consistent enough for EAC not to report an error (fewer than eight matches out of every set of sixteen re-reads).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-08-04 14:29:19
EAC's log only being "almost" perfect when it says there are errors.  It's quite possible for EAC to tell you there was an error even though the track was indeed ripped accurately.  This will usually happen when the most consistent data is accurate data but not consistent enough for EAC not to report an error (fewer than eight matches out of every set of sixteen re-reads).

The reverse situation also occurs: EAC reports "no errors", even though there are CRC mis-matches between Test and Copy on some tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-08-04 16:44:02
The reverse situation also occurs: EAC reports "no errors", even though there are CRC mis-matches between Test and Copy on some tracks.

Mismatched CRC's are not "errors"! That only tells that the 2 subsequent reads of that track differed. The "Copy" part of the ripping is the only deciding factor when EAC decides whether the rip was good or not.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-08-04 17:05:19
I stand on my position, I refrained answering to not enter in an endless debate with Greynol. I know that in the end we will both agree even if he may actually be convinced that we won't. I agree with the rare specials cases mentioned, I used "usually" or "near" (perfect) as I had those exceptions in mind ... & also as I knew Greynol wouldn't agree because it was not comprehensive in a scientific way. Those were just general guidelines on how to read a log, nevermind ... Furthermore I happily agree that Greynol's knowledge on audio is higher than mine ... so he doesn't even have to endlessly prove this point

More seriously, it's just that Greynol seems to have an ethic problem with telling a newbie a biased truth in order to save time, personnaly if I consider that my answer is right ~95% of time... I don't.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-04 17:15:15
Ethic problem?  Have you been smoking something?  Do you know what the word ethic even means?

What's this "biased truth" bs?  How has anything that I've said to fadsplat been biased?  Make that two words about which you should consult an English dictionary.

You sure have a funny way about communicating for someone who doesn't want to enter into a debate.

The guy wanted to know why his rip was deemed inaccurate and the answer is simple, the wording is wrong.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-04 17:19:12
Mismatched CRC's are not "errors"! That only tells that the 2 subsequent reads of that track differed.

CRCs that don't match most certainly indicate that either the test pass or the copy pass was done in error at the very least.

The "Copy" part of the ripping is the only deciding factor when EAC decides whether the rip was good or not.

...and it is well documented that EAC can tell you a rip is good when it really isn't (and vice-versa, though not as well documented).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: g725s on 2010-08-04 18:25:17
SNIP...I carefully read readme file...SNIP


Where is this elusive README file?  Does it include installation instructions?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dv1989 on 2010-08-04 18:37:15
Download (http://www.cuetools.net/doku.php/cuetools:download) CueTools, and if necessary .NET Framework 2 SP2 and Visual C++ 2008 Runtime, and run the executables. Voila: installation begins.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: g725s on 2010-08-04 18:56:09
Download (http://www.cuetools.net/doku.php/cuetools:download) CueTools, and if necessary .NET Framework 2 SP2 and Visual C++ 2008 Runtime, and run the executables. Voila: installation begins.


By executable you mean an install.exe?  If so, no such thing in the recent CUETools download I just unzipped.  Did you ever see a README file for CUETools?  I have read posts that I believe refer to it as also having some operating instructions.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dv1989 on 2010-08-04 19:24:22
Oh, sorry for the mistake. Now that you mention it, I remember that, having checked the archive for a readme yesterday in response to your question. Terrible memory.

In that case, installation is as simple as unzipping everything to a directory of your choice, then running the main executable from there.

There is a CUETools Documentation (http://www.cuetools.net/doku.php/cuetools:cuetools) link on Gregory's official CUETools site. I don't know if that is sufficient for you.
Furthermore, the old author Moitah's page (http://moitah.net/) suggests users "See the ReadMe.txt file included with the binary for help with the options." Perhaps that may be of some use (albeit outdated).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-08-05 00:08:38
The reverse situation also occurs: EAC reports "no errors", even though there are CRC mis-matches between Test and Copy on some tracks.

Mismatched CRC's are not "errors"! That only tells that the 2 subsequent reads of that track differed.

CRCs that don't match most certainly indicate that either the test pass or the copy pass was done in error at the very least.

Mismatched CRC's INDICATE something, but EAC doesn't report errors in the log when there's mismatched CRC's. Read the text which I was answering to (added that quote here).

The "Copy" part of the ripping is the only deciding factor when EAC decides whether the rip was good or not.

...and it is well documented that EAC can tell you a rip is good when it really isn't (and vice-versa, though not as well documented).

Both are correct. Was that just a complement or a try to refute what I wrote? Can't tell..
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-05 00:46:48
I don't think that fadsplat was ever suggesting that EAC bases its error messages (or lack thereof) on whether checksums match.

Anyway, I'm just trying to tie up any loose ends so this thing can get back on topic.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-08-05 01:12:46
My point was simply that when CRC values don't match, it at the very least raises the question as to whether or not the rip is accurate. But, since EAC reports "no errors", many people will read only that line and assume that everything is perfect.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2010-08-05 11:09:24
Using Cuetools 2.0.9. I found a possible bug.
I have ticked "Detect HDCD encoding" which I think works (not sure yet, must find another HDCD rip)
But when I tick Decode HDCD to 20 bit and store as 16bit lossy wav or store as 24bit lossless, then normal cd's are not written anymore (it gives a message:HDCD not detected)
IMHO when I tick Decode HDCD to 20 bit then normal cd's should not be affected by this setting.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-08-05 18:27:17
  • For some odd reason, when starting CUETools, my firewall kicks in and says that "CUETools.exe" is trying to start "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe" (Microsoft® Visual Studio® 2005 - Visual C# Command Line Compiler). It does this 8 times before CUETools window finally opens. And it happens EVERY time when starting CUETools. 2.0.4a never did this AFAIR (maybe the first time, can't remember..). I've ".NET Framework 2.0 SP2" & "Visual C++ 2008 runtime" installed. Recently I installed the ".NET Framework 4 Client Profile" from Windows updates (I've XP SP3), I wonder if that has something to do with this. Is it really required to run that csc.exe every time? CT starts very slowly.

It's the DLL files. Why was this changed so that csc.exe needs to compile (or whatever it does when it runs) the needed DLL's every time when running CUETools? Was this intended? Starting to really annoy. Especially when using the "/verify" cmdline feature. Hasn't anybody else noticed this "slowdown" starting CT?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: filou85 on 2010-08-06 14:01:14
Hello,

I'm new here.

I use CUERipper to encode my cds into FLAC files and I get the following error during the gap detection of Muse - Hullabaloo Soundtrack (disc 2) :

(http://img52.imageshack.us/img52/5/cueripperhullabaloo.jpg)

My cd have no scratch I can listen it without problem. I have ripped many cds with CUERipper and I never had this error. I also try to rip it with different cd players and have the same error.

Does my cd have a problem or it is a CUERipper bug?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-08-07 15:02:39
Does my cd have a problem or it is a CUERipper bug?

The CD contains a HTOA-track (you know, a hidden track before track 1) which your CD-drive doesn't seem to be able to support. CUEtools crashes the same way on my drive, so I think it's safe to say that this is a bug. My other drive that are capable of ripping HTOA works fine.

Maybe CUEtools should be fixed to rip a CD normally without that track, but give the user a notification of the presence of HTOA.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-08-07 15:06:51
Can someone explain this to me...

I ripped a scratched CD, obviously with errors. I use CUEtools to repair it using the known CTDB-entrys and receives the following output on the files. At first sight it seems like CTDB was not able to successfully repair the tracks, but apparently it was repaired to match all other offsetted releases:

Code: [Select]
[CUETools log; Date: 07-08-2010 15:56:52; Version: 2.0.9]
[CTDB TOCID: XTU4B7u6dvyQRuV9Lh992o1Udy8-] found.
[ CTDBID ] Status
[03e12bac] (336/336) Accurately ripped
[AccurateRip ID: 00144dd9-00d7a14c-b009520e] found.
Track  [ CRC ] Status
 01 [be97907b] (200/634) Accurately ripped
 02 [d18d8ea0] (200/630) Accurately ripped
 03 [f3637334] (200/629) Accurately ripped
 04 [b2430def] (200/629) Accurately ripped
 05 [fff3a34c] (200/633) No match but offset
 06 [9c6a5d54] (200/629) Accurately ripped
 07 [e17941b1] (200/636) Accurately ripped
 08 [7469e41b] (200/628) Accurately ripped
 09 [85da3c52] (200/629) Accurately ripped
 10 [c09b7265] (200/632) Accurately ripped
 11 [de212959] (200/627) Accurately ripped
 12 [ca7c1d6b] (200/628) Accurately ripped
 13 [87f097c4] (200/630) Accurately ripped
 14 [07abc8dd] (200/623) Accurately ripped
Offsetted by -1167:
 01 [651978b4] (067/634) Accurately ripped
 02 [5eb792bc] (066/630) Accurately ripped
 03 [622e7bfa] (067/629) Accurately ripped
 04 [1a1ef9a4] (067/629) Accurately ripped
 05 [1383964a] (067/633) Accurately ripped
 06 [78258c6b] (067/629) Accurately ripped
 07 [3cda3725] (067/636) Accurately ripped
 08 [a11fde9c] (067/628) Accurately ripped
 09 [3d5db722] (067/629) Accurately ripped
 10 [8ee75178] (067/632) Accurately ripped
 11 [f55f0015] (067/627) Accurately ripped
 12 [7477200d] (067/628) Accurately ripped
 13 [41e96bc5] (066/630) Accurately ripped
 14 [2bc5f796] (066/623) Accurately ripped
Offsetted by -503:
 01 [bb44e503] (144/634) Accurately ripped
 02 [d79a843b] (144/630) Accurately ripped
 03 [7d72be6b] (143/629) Accurately ripped
 04 [eb96d2ca] (144/629) Accurately ripped
 05 [e58e2fa8] (145/633) Accurately ripped
 06 [207e259d] (144/629) Accurately ripped
 07 [03241b2c] (145/636) Accurately ripped
 08 [7992c329] (145/628) Accurately ripped
 09 [d22d1c46] (143/629) Accurately ripped
 10 [3cead23d] (144/632) Accurately ripped
 11 [5d4e3751] (140/627) Accurately ripped
 12 [576e8f1a] (144/628) Accurately ripped
 13 [8ab56485] (144/630) Accurately ripped
 14 [9a18a194] (142/623) Accurately ripped
Offsetted by 166:
 01 [c44269b0] (064/634) Accurately ripped
 02 [9303797d] (063/630) Accurately ripped
 03 [fed762b3] (063/629) Accurately ripped
 04 [2a50612d] (061/629) Accurately ripped
 05 [8815c208] (062/633) Accurately ripped
 06 [e55bad13] (062/629) Accurately ripped
 07 [514a2236] (063/636) Accurately ripped
 08 [2a0e58b6] (062/628) Accurately ripped
 09 [fbff9a71] (062/629) Accurately ripped
 10 [27acb03b] (061/632) Accurately ripped
 11 [bdd16fe7] (061/627) Accurately ripped
 12 [88d50923] (061/628) Accurately ripped
 13 [73a45a43] (061/630) Accurately ripped
 14 [4cedf4be] (063/623) Accurately ripped
Offsetted by 278:
 01 [4f1ab971] (060/634) Accurately ripped
 02 [e2b5e515] (060/630) Accurately ripped
 03 [65115c17] (059/629) Accurately ripped
 04 [d402cdea] (060/629) Accurately ripped
 05 [2a5ae0b2] (062/633) Accurately ripped
 06 [300a8a9b] (059/629) Accurately ripped
 07 [3aa21a50] (061/636) Accurately ripped
 08 [d2bb4ed7] (061/628) Accurately ripped
 09 [05aadede] (060/629) Accurately ripped
 10 [8194c26f] (062/632) Accurately ripped
 11 [eaaa62f0] (062/627) Accurately ripped
 12 [665dbfc3] (060/628) Accurately ripped
 13 [930bdbad] (061/630) Accurately ripped
 14 [0a21c079] (057/623) Accurately ripped
Offsetted by -977:
 01 [807af0a0] (004/634) Accurately ripped
 02 [20b1f5d9] (004/630) Accurately ripped
 03 [08a1cd52] (004/629) Accurately ripped
 04 [550a4049] (004/629) Accurately ripped
 05 [62d77c7c] (003/633) No match but offset
 06 [6eced33c] (004/629) Accurately ripped
 07 [25a797c8] (004/636) Accurately ripped
 08 [3c37ee7c] (004/628) Accurately ripped
 09 [b2ba0689] (004/629) Accurately ripped
 10 [64ff866e] (004/632) Accurately ripped
 11 [e81dfaf6] (004/627) Accurately ripped
 12 [eaf0a728] (004/628) Accurately ripped
 13 [38f381b0] (004/630) Accurately ripped
 14 [43aa54ce] (004/623) Accurately ripped
Offsetted by -285:
 01 [1128fac9] (024/634) Accurately ripped
 02 [3a9b4950] (024/630) Accurately ripped
 03 [14d2deaa] (024/629) Accurately ripped
 04 [6bec140f] (024/629) Accurately ripped
 05 [8a39ae6c] (024/633) No match but offset
 06 [8a772c33] (024/629) Accurately ripped
 07 [c3e5189d] (025/636) Accurately ripped
 08 [0beb91d7] (021/628) Accurately ripped
 09 [e50521a4] (024/629) Accurately ripped
 10 [b59efd30] (025/632) Accurately ripped
 11 [f77a0bfb] (024/627) Accurately ripped
 12 [b8e90109] (023/628) Accurately ripped
 13 [928d106e] (024/630) Accurately ripped
 14 [d01d8cf2] (024/623) Accurately ripped
Offsetted by 379:
 01 [caf9809d] (071/634) Accurately ripped
 02 [3c1f37cf] (069/630) Accurately ripped
 03 [a3fb6e97] (069/629) Accurately ripped
 04 [a9af7b1a] (069/629) Accurately ripped
 05 [d9a2723f] (070/633) No match but offset
 06 [a06f11eb] (069/629) Accurately ripped
 07 [fc8ad8a8] (071/636) Accurately ripped
 08 [a67277b6] (068/628) Accurately ripped
 09 [5b1bc9d0] (069/629) Accurately ripped
 10 [321c3014] (069/632) Accurately ripped
 11 [b7960faa] (069/627) Accurately ripped
 12 [1a7d2de0] (069/628) Accurately ripped
 13 [cd58b4fa] (070/630) Accurately ripped
 14 [ad4d9913] (067/623) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100,0 [2FD7507D] [12032DE7] [E84B3A7D]
 01  97,7 [62C1C40C] [D578D2E8]  
 02  97,7 [F385CEDE] [E7A3EDB0]  
 03  97,7 [573ADCFF] [4112FC39]  
 04  97,7 [ABE73EE9] [F6CE68FF]  
 05  97,7 [300E75AF] [50D7AA68]  
 06  97,7 [59CD56CA] [BEED7545]  
 07  97,7 [80B92569] [70C11558]  
 08  97,7 [B18A1D07] [ACE5A70F]  
 09  97,7 [ACD0E700] [9D5E347B]  
 10  99,9 [0F5C0D3B] [51500113]  
 11  97,7 [7C6F9D97] [4A7E07AD]  
 12  100,0 [66630ECC] [A6C60D95]  
 13  97,7 [126A0B13] [82C0B378]  
 14  97,7 [5798FA0C] [0862B8F3]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-07 18:28:13
Your pressing differs from the pressing that is in the CTDB by more than just an offset.

Of all the pressings listed in the log it seems that there are three others that are a possible match to yours (besides the difference due to offset).

While this might not seem to be exactly common, it does happen.  If your copy of track 5 was previously verifiable against those other pressings you can locate the differences through subtracting the two and then determine which one is more correct.

I've tried to alert people to the possibility of this happening on more than one occasion in the past.  Here is one such post:
http://www.hydrogenaudio.org/forums/index....st&p=698717 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79882&view=findpost&p=698717)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-08-07 19:01:22
Wouldn't it then be more likely that CTDB corrected track 5 to match the other pressings, making the rip by this exact offset inaccurate?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-07 19:12:46
I don't know what you started with before the correction, but that's clearly what happened.

However, I don't see how that negates my explanation of the mechanism that caused the discrepancy.  Barring the possibility that one of the databases was polluted by an errant rip that was propagated through a CD-R/RW or file sharing, there are pressings that exist in which the audio data in track five differs by more than just an offset.  I identified such a situation in my collection just yesterday.

Are you able to get an error-free extraction of track five that can be verified by AR?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-08-07 19:33:44
But I don't think it's a "pollution". As far as I can see, it looks like CTDB are capable of repairing rips independently of offset. If only a CTDB submission exists for all the other offsets (which are similar in data), CTDB, will (?) repair my rip according to one of those.

Anyway, I could just offset it, and it will match another pressing just perfectly, although it seems kind of hackish...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-07 19:38:48
But I don't think it's a "pollution".
I just said barring the possibility of pollution.  I have no compelling reason to believe that the different pressings were caused by pollution.

As far as I can see, it looks like CTDB are capable of repairing rips independently of offset. If only a CTDB submission exists for all the other offsets (which are similar in data), CTDB, will (?) repair my rip according to one of those.
That's correct.

Anyway, I could just offset it, and it will match another pressing just perfectly, although it seems kind of hackish...
Whatever floats your boat.

If you like, I can check my copy of Dookie to see which audio data I have for track 5.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-08-07 20:53:36
I thought I'd play around with it anyway and managed to successfully convert my disc that has a different TOC into the one that you have, though I am not able to get CUETools to correct it using CTDB.

Code: [Select]
[CUETools log; Date: 8/7/2010 12:48:37 PM; Version: 2.0.9]
[CTDB TOCID: XTU4B7u6dvyQRuV9Lh992o1Udy8-] found.
        [ CTDBID ] Status
        [03e12bac] (336/336) No match
[AccurateRip ID: 00144dd9-00d7a14c-b009520e] found.
Track  [ CRC    ] Status
 01    [be97907b] (200/634) Accurately ripped
 02    [d18d8ea0] (200/630) Accurately ripped
 03    [f3637334] (200/629) Accurately ripped
 04    [b2430def] (200/629) Accurately ripped
 05    [627aac23] (200/633) Accurately ripped
 06    [9c6a5d54] (200/629) Accurately ripped
 07    [e17941b1] (200/636) Accurately ripped
 08    [7469e41b] (200/628) Accurately ripped
 09    [85da3c52] (200/629) Accurately ripped
 10    [c09b7265] (200/632) Accurately ripped
 11    [de212959] (200/627) Accurately ripped
 12    [ca7c1d6b] (200/628) Accurately ripped
 13    [87f097c4] (200/630) Accurately ripped
 14    [936cc134] (200/623) No match but offset
Offsetted by -1167:
 01    [1c52cb4a] (067/634) No match but offset
 02    [5eb792bc] (066/630) Accurately ripped
 03    [622e7bfa] (067/629) Accurately ripped
 04    [1a1ef9a4] (067/629) Accurately ripped
 05    [7a248e94] (067/633) No match but offset
 06    [78258c6b] (067/629) Accurately ripped
 07    [3cda3725] (067/636) Accurately ripped
 08    [a11fde9c] (067/628) Accurately ripped
 09    [3d5db722] (067/629) Accurately ripped
 10    [8ee75178] (067/632) Accurately ripped
 11    [f55f0015] (067/627) Accurately ripped
 12    [7477200d] (067/628) Accurately ripped
 13    [41e96bc5] (066/630) Accurately ripped
 14    [47035c89] (066/623) No match but offset
Offsetted by -977:
 01    [3127f0c6] (004/634) No match but offset
 02    [20b1f5d9] (004/630) Accurately ripped
 03    [08a1cd52] (004/629) Accurately ripped
 04    [550a4049] (004/629) Accurately ripped
 05    [a50bd0c0] (003/633) Accurately ripped
 06    [6eced33c] (004/629) Accurately ripped
 07    [25a797c8] (004/636) Accurately ripped
 08    [3c37ee7c] (004/628) Accurately ripped
 09    [b2ba0689] (004/629) Accurately ripped
 10    [64ff866e] (004/632) Accurately ripped
 11    [e81dfaf6] (004/627) Accurately ripped
 12    [eaf0a728] (004/628) Accurately ripped
 13    [38f381b0] (004/630) Accurately ripped
 14    [82c5de09] (004/623) No match but offset
Offsetted by -503:
 01    [13e8ace0] (144/634) No match but offset
 02    [d79a843b] (144/630) Accurately ripped
 03    [7d72be6b] (143/629) Accurately ripped
 04    [eb96d2ca] (144/629) Accurately ripped
 05    [4e3ceaba] (145/633) No match but offset
 06    [207e259d] (144/629) Accurately ripped
 07    [03241b2c] (145/636) Accurately ripped
 08    [7992c329] (145/628) Accurately ripped
 09    [d22d1c46] (143/629) Accurately ripped
 10    [3cead23d] (144/632) Accurately ripped
 11    [5d4e3751] (140/627) Accurately ripped
 12    [576e8f1a] (144/628) Accurately ripped
 13    [8ab56485] (144/630) Accurately ripped
 14    [40287527] (142/623) No match but offset
Offsetted by -285:
 01    [fb41f9d5] (024/634) No match but offset
 02    [3a9b4950] (024/630) Accurately ripped
 03    [14d2deaa] (024/629) Accurately ripped
 04    [6bec140f] (024/629) Accurately ripped
 05    [a363ad4c] (024/633) No match but offset
 06    [8a772c33] (024/629) Accurately ripped
 07    [c3e5189d] (025/636) Accurately ripped
 08    [0beb91d7] (021/628) Accurately ripped
 09    [e50521a4] (024/629) Accurately ripped
 10    [b59efd30] (025/632) Accurately ripped
 11    [f77a0bfb] (024/627) Accurately ripped
 12    [b8e90109] (023/628) Accurately ripped
 13    [928d106e] (024/630) Accurately ripped
 14    [26114edd] (024/623) No match but offset
Offsetted by 166:
 01    [c44269b0] (064/634) Accurately ripped
 02    [9303797d] (063/630) Accurately ripped
 03    [fed762b3] (063/629) Accurately ripped
 04    [2a50612d] (061/629) Accurately ripped
 05    [eb203b91] (062/633) No match but offset
 06    [e55bad13] (062/629) Accurately ripped
 07    [514a2236] (063/636) Accurately ripped
 08    [2a0e58b6] (062/628) Accurately ripped
 09    [fbff9a71] (062/629) Accurately ripped
 10    [27acb03b] (061/632) Accurately ripped
 11    [bdd16fe7] (061/627) Accurately ripped
 12    [88d50923] (061/628) Accurately ripped
 13    [73a45a43] (061/630) Accurately ripped
 14    [3b6388bd] (063/623) No match but offset
Offsetted by 278:
 01    [4f1ab971] (060/634) Accurately ripped
 02    [e2b5e515] (060/630) Accurately ripped
 03    [65115c17] (059/629) Accurately ripped
 04    [d402cdea] (060/629) Accurately ripped
 05    [e104f98b] (062/633) No match but offset
 06    [300a8a9b] (059/629) Accurately ripped
 07    [3aa21a50] (061/636) Accurately ripped
 08    [d2bb4ed7] (061/628) Accurately ripped
 09    [05aadede] (060/629) Accurately ripped
 10    [8194c26f] (062/632) Accurately ripped
 11    [eaaa62f0] (062/627) Accurately ripped
 12    [665dbfc3] (060/628) Accurately ripped
 13    [930bdbad] (061/630) Accurately ripped
 14    [28ae7cb8] (057/623) No match but offset
Offsetted by 379:
 01    [caf9809d] (071/634) Accurately ripped
 02    [3c1f37cf] (069/630) Accurately ripped
 03    [a3fb6e97] (069/629) Accurately ripped
 04    [a9af7b1a] (069/629) Accurately ripped
 05    [f4da33e7] (070/633) No match but offset
 06    [a06f11eb] (069/629) Accurately ripped
 07    [fc8ad8a8] (071/636) Accurately ripped
 08    [a67277b6] (068/628) Accurately ripped
 09    [5b1bc9d0] (069/629) Accurately ripped
 10    [321c3014] (069/632) Accurately ripped
 11    [b7960faa] (069/627) Accurately ripped
 12    [1a7d2de0] (069/628) Accurately ripped
 13    [cd58b4fa] (070/630) Accurately ripped
 14    [8e13c99e] (067/623) No match but offset

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [59354DB9] [196815AC]         
 01  97.7 [4B62A514] [9D18C343]  CRC32 
 02  97.7 [F385CEDE] [E7A3EDB0]  CRC32 
 03  97.7 [573ADCFF] [4112FC39]  CRC32 
 04  97.7 [ABE73EE9] [F6CE68FF]  CRC32 
 05  97.7 [02F9CDA8] [A12D2B6C]  CRC32 
 06  97.7 [59CD56CA] [BEED7545]  CRC32 
 07  97.7 [80B92569] [70C11558]  CRC32 
 08  97.7 [B18A1D07] [ACE5A70F]  CRC32 
 09  97.7 [ACD0E700] [9D5E347B]  CRC32 
 10  99.9 [0F5C0D3B] [51500113]  CRC32 
 11  97.7 [7C6F9D97] [4A7E07AD]  CRC32 
 12  100.0 [66630ECC] [A6C60D95]  CRC32 
 13  97.7 [126A0B13] [82C0B378]  CRC32 
 14  97.7 [E4F62D0D] [576D6E64]  CRC32 
Any assistance would be appreciated.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Rollin on 2010-08-07 21:21:12
When CUETools converts HDCD data to 24 bit lossless does it apply peak extend, transient filter and gain to sound data?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Aeternus on 2010-08-08 16:22:13
CUETools is constantly giving me an array index out of bound exception when trying to process any cue file ...



It happens with all CUE files I have, it didn't earlier. 
Also, it happens before or after checking MusicBrainz, so I guess it's not related to the cue files at all.


Same here! It even happens with rips I made with CUERipper just minutes ago. My old EAC rips (a mixture of image + cue and individual files + cue) give the same error.

Interestingly, AR verification is possible. I just get that exception when trying to transcode. Sometimes before querying MusicBrainz, sometimes after. My previous version of CUETools (2.0.2a) didn't have that issue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dirki on 2010-08-08 22:14:59
When I use this format with Cue-Tools

[%directoryname%\]%artist% - %album% '('%year%')'[%unique%]\%filename%.cue

how can I make it, that instead of this output (showing the variable %year%)

Rah Band - Rah (%year%)

nothing (instead of %year%) will be displayed, when the year is missing in the data:

Rah Band - Rah
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-08-09 21:49:04
Hello:

I downloaded a rip made by someone else. There is no cue file, only an EAC log from an unspecified version. When I use EAChelper's log analyzer (http://eachelper.uphero.com/Analyzehtml.php) it says: "Incorrect read offset for LITE-ON LTR-52327S The read offset for LITE-ON LTR-52327S should be +6." The log shows that Read offset correction was 0.

When I use CueTools to verify the tracks, by dragging the first .wav file onto CueTools. the result is this:

Code: [Select]
[CUETools log; Date: 09/08/2010 4:20:35 PM; Version: 2.0.9]
[CTDB TOCID: _Aw5sadEbfyx850rLpfAssw1T2w-] found.
        [ CTDBID ] Status
        [19ddeccc] (5/5) Accurately ripped
[AccurateRip ID: 000dbd35-00706562-79091d0a] found.
Track   [ CRC    ] Status
01     [49334af4] (02/09) Accurately ripped
02     [fb9a597f] (02/08) Accurately ripped
03     [97dc1da3] (02/09) Accurately ripped
04     [12c2f36d] (02/09) Accurately ripped
05     [b57fbdc2] (02/09) Accurately ripped
06     [d4358d5e] (02/09) Accurately ripped
07     [548953b8] (02/09) Accurately ripped
08     [82848983] (02/09) Accurately ripped
09     [a2fe8bf8] (03/10) Accurately ripped
10     [b918da29] (02/09) Accurately ripped
Offsetted by 6:
01     [abc59c3f] (07/09) Accurately ripped
02     [f30a350d] (06/08) Accurately ripped
03     [ac353f87] (07/09) Accurately ripped
04     [377c760f] (07/09) Accurately ripped
05     [c77d951b] (07/09) Accurately ripped
06     [4ecad046] (07/09) Accurately ripped
07     [fd29ebb1] (07/09) Accurately ripped
08     [554e4742] (07/09) Accurately ripped
09     [6f8b0943] (07/10) Accurately ripped
10     [ed4db42f] (07/09) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   87.9 [F0842CFA] [FE10AB4A]
01   45.7 [8CAFE107] [5EEE4117]
02   49.7 [F9501052] [3395475C]
03   40.9 [240C3F17] [50F1D520]
04   53.7 [65DB5693] [95856A3A]
05   68.8 [9E85FD6B] [708E25E5]
06   47.0 [63A61B38] [C5D11F6F]
07   71.4 [18DD8958] [6D7E3DB0]
08   87.9 [5EE0CB38] [430A092C]
09   67.2 [B301B89E] [FC001F59]
10   63.2 [1F292BD2] [B00BC890]


CueTools has a function called "fix offset", but I do not know exactly what it does or how to use it. Should I use it in this case? How would I do so, and what would the benefit be?

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: g725s on 2010-08-10 05:25:00
Is there a good guide online on how to use CUETools?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2010-08-10 16:57:57
Is there a good guide online on how to use CUETools?

A quick search would have found a guide on the previous page.

http://www.hydrogenaudio.org/forums/index....st&p=716848 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=716848)

It is a work in progress needs people to contribute.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: g725s on 2010-08-11 01:58:28
Is there a good guide online on how to use CUETools?

A quick search would have found a guide on the previous page.

http://www.hydrogenaudio.org/forums/index....st&p=716848 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=716848)

It is a work in progress needs people to contribute.



Are you calling this (http://www.cuetools.net/doku.php/cuetools:cuetools) a guide / tutorial?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-08-15 17:18:47
After starting to rip my CD's with CUEripper (in tracks mode), I noticed many albums, which gives me a HTOA-file usually only consisting of 18816 samles (some more). I suspect this is equivalent of PREGAP. They can of course contain audio, in which case they should surely be preserved, but what should I do with all those without audio?

It seems a bit odd to keep them, but deleting them will break the CUE-sheet. Maybe an option to convert them into PREGAP instead would be the best way to fix it?

Besides this, I have a few issues/requests:

1. Verifying albums in batch mode, if an album consists of short tracks that are not kept in the AR-database, it will report "AR inaccurate" even when the album says accurate when it's verified alone.
2. The log output is great, but could certainly be improved. How about a cell-matrix with columns instead of everything on one line?
3. CT can correct filenames in cue-files, but it would be great if you could also rename log+cue+accurip using a template.
4. CT can't distinguish multiple CD-albums with more than 9 albums in one folder?
5. "Output file already exists, Overwrite?" (.accurip) is quite annoying. Can we have an option to always overwrite at least this file?
6. Why are HTOA tracks not tagged? (Edit: This seems to be a problem if you want to rename an album with a HTOA-track)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: earui on 2010-08-16 15:05:43
Thx for your nice work!!!

Startet today with CueTools after rEACt making Problems with Win7 (x64) on my new computer.
And CueTools seems to work how I intend: Making simply exact Images as Flac with Cue-Sheet.

I tried several templates to achive the same Name-Structur as I did in Foobar2000 or rEACt before.
I thought while: "cuetools output path templates are based on foobar2000 title formatting syntax", I should be able to take my formating string from Foobar2000.
But it doesn´t work.

Here is my f2k formatting string:
%music%\$left(%album artist%,1)\%album artist%\['['%date%']' ]%album%\$if(%disc%,CD$num(%disc%,1)\,)[$if2(%vinyltrack%,%tracknumber%)] %title%

or for single image files
%music%\$left(%album artist%,1)\%album artist%\['['%date%']' ]%album%\$if(%disc%,CD$num(%disc%,1)\,)%album artist% - %album%

to make this structure:
music\A\Alex\[2009] Test\Alex - Test.flac

and if more than 1 disc:
music\A\Alex\[2009] Test\cd1\Alex - Test.flac
music\A\Alex\[2009] Test\cd2\Alex - Test.flac

Could you please help me doing this with CueTools?
It´s not such a big problem to "handmade" this  later on, but it would be nice if CueTools could handle this too!!!

(Sorry for my bad english.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: worsel on 2010-08-18 02:06:45
I am new to Cuetools/Cueripper etc.  Is there a way to make Cueripper eject a CD automatically after it is ripped?  I'd like to automate the ripping process if possible.

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radivx on 2010-08-18 11:33:43
Hi!
I really like the progress of the CUETools development


Currently I've got two problems/questions that I'd love to see a fix for:

1) It seems that CUERipper has a problem with UTF-8 in cue sheets:

CUETools are able to save Japanese artists in the CUE sheet,
but CUERipper only sets ????? as artist name.

I also think there should be an option to use Latin names (like the
option found in MusicBrainz Picard).

2) I've got a EAC rip of the Emperor: Battle for Dune soundtrack.
However since no one has added the disc id to MusicBrainz, CUETools
are not able to get the related metadata from MusicBrainz.

Is there a way I can force CUETools to use a specific metadata entry?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cerebus on 2010-08-18 18:13:47
I generally use Cuetools to split full album flac files into pieces using cuesheets - but my files reside on a Linux machine.  I've run Cuetools on the files remotely through Samba and in Virtualbox, and I've found that the order of the directories/files in my network shares are not sorted alphabetically like dirs/files on my local filesystem.  It'd be great if these could be sorted.

Awesome program.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NappyHead on 2010-08-25 17:48:18
This tools has become invaluable to me and I use it often, but i would like to make one request. Can you include an "if exist" feature, with to option to create new, overwrite etc.

Thank you

NH
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: osaldus on 2010-08-30 07:39:16

Will like to know if there is a way to just save a new cuesheet after a freedb lookup. Let me explain the cases i'm facing.
I'm trying to organize a unattended batch ripping done with dbpoweramp months ago and have seen that many times dbpoweramp picked up a wrong reference from its sources; common examples are:
- the same album has been released in two languages, and it picked the wrong one;
- the same album has been released in various countries and instead of english titles it picked the japanese ones;
- someone long ago put his cd on the drive, named all wrong, and then hit the cddb upload icon (happens frequently with Brazilian artist, don't know why).
- with the same cd_id there are more than one entry (especially true for cd singles)
- someone swapped artist/song when editing his cd then submitted it to cddb or whatever.
Given that everything else is already encoded in flac, there is a way to just save a new and correct cuesheet from a lookup without doing a flac_2_flac re-encoding or doing a manual editing?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: osodeh on 2010-09-09 11:02:17
I really want to test out and use CueRipper,  but I just can't get the proxy settings to work. Strangely, I can get the proxy settings working for CueTools (for verifying against AccurateRip) and since i assume the same settings in CueTools carry over to CueRipper, I am at a total loss. Is there any possible explanation for this behavior? I will try to attach some images that might explain demonstrate what I mean.... if I can get the images to post, I am sort of new to this..One image is supposed to show the album verified using accurate rip with confidence levels (implying that my proxy settings work in CueTools) but I cannot get values (tracks, artist, album meta info) from the ripper using the same proxy information. Is there a separate configuration page for the ripper that I am missing?
Many thanks in advance to anyone who might be able to point me in the right direction.

[attachment=6053:CueTools.jpg]

[attachment=6054:CueRipper.jpg]

I hope this is clear, and thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2010-09-26 17:06:51
I downloaded a rip of John Lennon Mind Games. Track 06 has a result I have never seen before.
Please comment and explain what this result means.

The .accurip report from CueTools has an odd result for track 06:
06    [00000000] (0/0) Accurately ripped

And for "Track Peak", it shows this:
06    0.0 [648C227C] [00000000] [3ED0B63C]: W/O NULL for track 5

The rip log also shows a zero peak level for track 06:
Track  6

    Filename E:\Tmp\MG\06. Nutopian International Anthem.wav

    Peak level 0.0 %
    Track quality 98.1 %
    Track not present in AccurateRip database
    Copy OK


Here is the .accurip report from CueTools. Note track 06:
Code: [Select]
[CUETools log; Date: 03/09/2010 12:36:17 PM; Version: 2.0.9]
[CTDB TOCID: AzwZ2tvGRf0gfAkKCwDT.1s5Elo-] disk not present in database.
[AccurateRip ID: 0012ccc9-00ac901c-8c09960c] found.
Track   [ CRC    ] Status
01     [2a921a9c] (2/2) Accurately ripped
02     [eb24f9cf] (2/2) Accurately ripped
03     [1707fe4e] (2/2) Accurately ripped
04     [62657db1] (2/2) Accurately ripped
05     [0f3455d1] (2/2) Accurately ripped
06     [00000000] (0/0) Accurately ripped
07     [ab3e4ace] (2/2) Accurately ripped
08     [a48879cb] (2/2) Accurately ripped
09     [bdb747c3] (2/2) Accurately ripped
10     [669a84ac] (2/2) Accurately ripped
11     [97d6ca03] (2/2) Accurately ripped
12     [da97b8ac] (2/2) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--  100.0 [31A64405] [4872CE78]
01  100.0 [BAF4D9EF] [0FDCDFF1]  W/O NULL
02   92.4 [3BBA0ADE] [8EB80D5C] [0FDCDFF1]: W/O NULL for track 1
03   97.4 [21322C5B] [95FCAA49] [8EB80D5C]: W/O NULL for track 2
04   90.0 [41FB1B3D] [0F810A11] [95FCAA49]: W/O NULL for track 3
05   93.7 [38981321] [3ED0B63C] [0F810A11]: W/O NULL for track 4
06    0.0 [648C227C] [00000000] [3ED0B63C]: W/O NULL for track 5
07   81.8 [D62A1ADD] [90F9803C]  W/O NULL
08   74.5 [61FDCB9F] [6FAE9F3B]  W/O NULL
09   82.3 [07800E57] [4852044B]  W/O NULL
10   81.7 [2E23CC2C] [6ECB6A32]  W/O NULL
11   84.8 [7A065274] [E7EFED6F]  W/O NULL
12   84.6 [11179527] [4C5199CB]  W/O NULL


The rip log has this AccurateRip reporting at the end:
11 track(s) accurately ripped
1 track(s) not present in the AccurateRip database

If you want to see the full log, it's on pastebin (I didn't want to make this post too lengthy and awkward to read), so you can see the log here: http://pastebin.com/Q6DsqKDN (http://pastebin.com/Q6DsqKDN)

Track 06 has a result I have never seen before. Please comment and explain what this result means.
Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2010-09-26 18:09:51
I downloaded a rip of John Lennon Mind Games. Track 06 has a result I have never seen before.


first, read the TOS before you post a question regarding illegal downloads, this can get you banned.

second, Track 6 on that album is just a few seconds of complete silence. that's why it has no peak value, no crc and is not present in the AR database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-09-26 18:28:28
read the TOS before you post a question regarding illegal downloads

Unfortunately discussing/requesting help with pirated material is not prohibited. Unfortunately.

Choose silence treatment.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-09-26 20:00:34
Akkurat is right, though these posts aren't exactly on-topic.

The discussion is about CUETools.  It is not the fadsplat support thread.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2010-10-08 14:44:04
has anyone noticed very slow access of the accuraterip database since the recent update (yesterday i think) - just wondered if it was a deliberate throttle to prevent too many people hammering the server or whether my (new) cuetools setup on my new laptop needed a bit of fine tuning
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Est on 2010-10-08 20:22:32
Can't add md5 checksum in WavPack, please fix this problem.
I have already asked, but you didn't fix it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-10-09 03:43:31
Gregory S. Chudov, do you have any interest/time to develop CUETools (or fix remaining bugs) anymore? Good to see that you're back in HA (at least reading/visiting), I actually had a bad feeling about your absence.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2010-10-09 10:03:57
has anyone noticed very slow access of the accuraterip database since the recent update (yesterday i think) - just wondered if it was a deliberate throttle to prevent too many people hammering the server or whether my (new) cuetools setup on my new laptop needed a bit of fine tuning


fine this morning.. no worries.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 2010-10-09 13:45:49
If development is being continued on the CUEtools package, I have a few simple requests for CUEripper:

1. Please allow some sort of obvious notification that HTOA is available. A popup message would be preferable, as I have some drives that do rip HTOA data and some that doesn't.

2. Please make a notification is files already exists instead of just overwriting them. Helps avoid accidential unnessesary double-rips when you rip large batches

3. Please allow an option to eject the drive after ripping (helps same issue as above).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-11-01 00:26:32
Now that's weird.
I managed to split one flac file into single flac files by disabling freedb and Musicbrainz. No "array index out of bound". Then I switched to mp3 - and the error is back, also with flac files ...

I wonder if it wil be fixed some day.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-11-07 16:13:12
Gregory S. Chudov, do you have any interest/time to develop CUETools (or fix remaining bugs) anymore?

Could you please answer something? If you don't want to continue anymore, maybe somebody could take over (start fixing the numerous bugs/problems & perhaps develop it further) once you say that you're done with it. Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2010-11-07 16:49:23
There is development in SVN. Latest changes: Nov 05.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-11-07 19:18:00
Other development than GPU stuff (http://www.hydrogenaudio.org/forums/index.php?showtopic=64628&st=200) (AFAIU) Chudov is doing nowadays? (= ~4 months ago according to the repo)

I don't want to be an asshole and demand that somebody answers my question/bug/problem posts (lots of which date back to January BTW), I just thought that coming out and saying that he's not interested in this project anymore (because it doesn't offer interesting coding "challenges" anymore (he has stated this himself)) _might_ arouse some other developer to embrace this project and "finish" the app (bug crunching/polishing).

I can live with the numerous bugs/problems (I only use it to verify from cmd line), except the 1st problem I posted back in July (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=714492) (the 1st point about CT opening/starting slowly because csc.exe runs many many times every time CT is ran).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Qest on 2010-11-07 19:39:25
It's open source. If you want to fix bugs then go ahead and do so.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: necropimp on 2010-11-07 21:01:23
a few problems i'm running into running this in linux (ubuntu 10.04)

1. all i can get it to do is verify and correct filenames... encoding in any format is a no go
2. clicking on settings causes cuetools to crash
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-11-08 16:33:05
It's open source. If you want to fix bugs then go ahead and do so.

Thanks but I didn't ask about that. If I'd have time, I would do just that.

Hopefully somebody takes over the development someday..
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2010-11-08 16:51:41
Hopefully somebody takes over the development someday..


...just plain no. He's got the right for a break after last year's killer development. The important part of the code is quite stable.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 2010-11-08 18:57:33
He's got the right for a break after last year's killer development.

Break is always ok.. but unfortunately the facts indicate that he very well _might_ be over with CT development (= it doesn't offer interesting coding "challenges" anymore). Also, the lack of posting here doesn't look promising. + While this is not intended to be about myself, I can't disregard the fact that my first big post (and the 2nd one) with questions/bugs/problems from January is still hanging (of course he doesn't have to answer.. but still, it's a thing that I can't pass when stating my fears about the future of the development).

And can't projects have more than 1 developer? This is not about superseding Chudov, it's about arousing an interest for somebody to help code stuff that he doesn't bother to do. Is this a bad thing to say? He has said it himself and to me, there's nothing bad about that, he's wonderfully honest. Can we stop the defending now and move on? (This went on too long, this is my last post about this.) In case somebody misunderstood, my agenda is not to defame anybody (well, maybe unintentionally myself ), I'm really interested about CT and it's future.

The important part of the code is quite stable.

YMMV.  I slightly disagree, there are many bugs, and the profile/settings system is a bit of a mess (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=679211).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2010-11-09 00:43:58
I agree with Akkurat.

Users who think that a developper stops development for a year or two, just to suddenly restart after a long vacation are just naive computer newbies.

[Sarcastic mode: on] Maybe some of the old HA musepack zealots who bought Franck Klemm a new PC (and since then most likely switched to lossless) wanna try again & buy Gregory a new computer to relaunch his interest ? ... some people never learn ... [Sarcastic mode: off]

joke apart, Gregory did a wonderfull job, he pushed CT further than I would even have imagined (specially as I was already a CT user before he added AR support), ... but in case new users don't realize it: CT already had 2 lifes & two main developers. Despite being a nice person & a skilled dev, Gregory has lost interest in CT around the same time he started playing with Cuda ... & also maybe because he might have found a job in real life as I recall he said he would "die for a job in Canada" & I recently read in another topic that he actually had a job.

There is nothing bad in it, that's life. But as far as I understund Akkurat, what he is asking for is a clear development status for CT.
CT has reached the point where it is almost as usefull as EAC or F2K for some people & some use (which, by the way, is a tremendous compliment). It is just too usefull to let it die as the average project.

The only problem with what Akkurat is asking for is that most likely Gregory himself doesn't know what he wants... I am pretty sure that he still reads the topic despite being mute. As a comparison, recently JMValin pm me & asked me to ABX an unreleased CELT version before he can froze the code ... the only problem is that personnaly I have lost all interest in lossy audio, so ironically the only reason why I would have an interest in ABXing CELT is video: if both Webm would be better than x264, & at the same time CELT would be better than Vorbis, & overall if Webm+CELT would be better than x264+nero aac which in the end is very very unlikely ... so as I didn't knew what to answer to him (& I didn't wanted to discourage him) I just didn't answer (how courageous of me ...)... just like Gregory for CT IMHO.

So the real question is who is gonna take over now that Gregory is lost in space ??? The worries of Akkurat only reflects the fact that he knows it is no trivial task that the average joe reading HA can do. Many HA newbie thinks that, CT being open source, it cannot die, this is plain false, CT can enter an "age of cold" where it can remain frozen for years, & at some point it might die of neglect. Being open source doesn't make a software immune to death, it only makes its agony last forever, because hope is what dies last.

A sad thing for me, is that I am convinced that newbies always asking again & again the same questions about AR has played a big part in his loss of interest, I am not sure that he realized that he would have to do the "customer service" of .accurip log reading when he added AR support to CT. At the time, I tried to answer some newbies questions but it often brought me trouble with Greynol as my knowledge was incomplete. So I begun thinking that CT needed a real FAQ & I slowly stop answering as I get bored myself. For me CT development took a wrong path as this topic slowly became unreadable, it's as if all the F2K forums would be joined in a single topic... CT is too large for such a reduction.

The saddest thing for CT is that despite being slightly buggy, unpolished & overall not finished featurewise, in most cases it works great.
If Gregory has done all his personnal ripping/conversion & checking against AR, it's obvious that sadly he might not even use CT daily anymore himself.

Hopefully at some point he will realize by himself that Cuda & co are just useless child toys & that CT is the real thing ... I am convinced that even if he doesn't use CT daily anymore, he will realize that he still use it regulary, & that, as a "can't live without software", it deserves to be polished.
As a comparison nowadays EAC development is very slow, but in the end it doesn't matter because it is very stable. The problem with CT is that it hasn't reached this status. So even if Gregory stop adding new feature to CT, it would be nice he could stabilize what he already added, so that if ever someone takes over the development he doesn't start with a half-broken toy. Like Akkurat pointed the profile system has always been experimental to my eyes (I don't even use it, I never understund where Gregory wanted to go with it ...), but there are plenty of other little glitches left everywhere that hinders the CT experience, like CD with silent track not being reported as accurate in the batch log for exemple.

Anyway, thks for what you've done & see ya soon silent one
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2010-11-09 05:42:25
sauvage78, does this remind you of something?
"...Let's compare apples to apples, m'kay?"

Only a few months have passed since the last release and you already made the funeral for CueTools. Despite polishing that is needed, this program starts to become mature and the developer can keep working on it on a slower pace, even if it doesn't offer new coding challenges. It's up to him to decide.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2010-11-09 06:53:26
I think his work thus far has been nothing short of tremendous and I would love to see refinements in CUE Ripper.  Work on the documentation would be phenomenal as well.

This thread is monstrous and I regret my role in bloating it with nitpicking over some of the finer details.  Still, it is smaller than the REACT discussion and some of the dedicated support threads over in the fb2k forum.  Either way I doubt I'm the only one who finds the sheer size quite intimidating when trying to learn about the program.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-11-09 22:17:47
I do read this topic from time to time  But it don't have time to answer, and i don't think short messages like "i'm still alive" and "i'll look into it sometime later" would do anybody any good. Thanks for understanding and kind words.

It is an exaggeration to say i stopped developing CUETools. I consider hardware-accelerated FLAC encoder a very important feature for the future of CUETools. Not everyone has a powerfull GPU, yes, but very soon everybody will have at least quad-core CPU with advanced vector instructions. The future is in parallel processing.

If anybody wants to work on other parts, like fixing the profiles system or adding AccurateRip2 support, just drop me or jdp a message to get access to souceforge repository.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zsero on 2010-11-16 19:05:10
Can someone show me a script for
1. encode into file-new.flac
2. removing original files if the encoding is successful
3. rename file-new into original file

All I want to do actually is to use the magnificent CUE embedding capabilities of CUETools on a batch of folders. It would be perfect if not even encoding would be required, but given today's FLAC speed its not that bad.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: indigital on 2010-11-17 00:25:55
Dear folks,

unfortunately I'm suffering on a freshly installed Windows 7 X64 from a crash right from the spot after having started Cuetools 2.0.9.
It just leads to a dialog where I get informed that Cue Tools has stopped working. The details of that dialog are pointing - among others - at "CLR20r3" and  a "System.ArgumentException".
I assume all .NET elements to be installed correctly.
I would be pleased if someone threw in some thoughts about solving my issue ...

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2010-11-18 00:35:29
I assume all .NET elements to be installed correctly


Not a good assumption. A number of times I suddenly have had problems with .net programs that required reloading .net. Once , after a microsoft update, I had to completely uninstall everything and reload to resolve the problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Jan S. on 2010-11-18 19:29:07
Gregory:
If you have time could you please check out this wiki page: http://wiki.hydrogenaudio.org/index.php?ti...n_of_CD_rippers (http://wiki.hydrogenaudio.org/index.php?title=Comparison_of_CD_rippers)
There are some blanks for CueTools where we don't know exactly what it is doing. It would be nice to complete this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2010-11-20 12:19:26
Done.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: necropimp on 2010-11-22 01:59:50
i am experiencing the following problems running cuetools 2.0.9 in the latest mono version (2.6.something) in ubuntu 10.04

1. clicking on the settings button crashes cuetools
2. trying to encode the only option i have is wav and that gives me an error

this is everything that comes up when i run cuetools with mono from the terminal
Code: [Select]
Error loading UIA bridge (UiaAtkBridge, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f4ceacb585d99812): System.IO.FileNotFoundException: Could not load file or assembly 'UiaAtkBridge, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f4ceacb585d99812' or one of its dependencies. The system cannot find the file specified.
File name: 'UiaAtkBridge, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f4ceacb585d99812'
  at System.AppDomain.Load (System.String assemblyString, System.Security.Policy.Evidence assemblySecurity, Boolean refonly) [0x00000] in <filename unknown>:0
  at System.AppDomain.Load (System.String assemblyString) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.AppDomain:Load (string)
  at System.Reflection.Assembly.Load (System.String assemblyString) [0x00000] in <filename unknown>:0
  at System.Windows.Automation.Provider.BridgeManager.GetAutomationBridge () [0x00000] in <filename unknown>:0
this is what comes up when i click settings and cuetools crashes
Code: [Select]
System.NullReferenceException: Object reference not set to an instance of an object
  at JDP.frmSettings.encodersBindingSource_CurrentItemChanged (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.OnCurrentItemChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.<ConnectCurrencyManager>m__5 (System.Object o, System.EventArgs args) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.CurrencyManager.OnCurrentChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.CurrencyManager.ChangeRecordState (Int32 newPosition, Boolean validating, Boolean endCurrentEdit, Boolean firePositionChanged, Boolean pullData) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.CurrencyManager.UpdateIsBinding () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.CurrencyManager.ListChangedHandler (System.Object sender, System.ComponentModel.ListChangedEventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.OnListChanged (System.ComponentModel.ListChangedEventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.ResetBindings (Boolean metadataChanged) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.SetList (IList l) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.ResetList () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.OnParentCurrencyManagerChanged (System.Object sender, System.EventArgs args) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.CurrencyManager.OnMetaDataChanged (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.CurrencyManager.ListChangedHandler (System.Object sender, System.ComponentModel.ListChangedEventArgs e) [0x00000] in <filename unknown>:0
  at (wrapper delegate-invoke) System.ComponentModel.ListChangedEventHandler:invoke_void__this___object_ListChangedEventArgs (object,System.ComponentModel.ListChangedEventArgs)
  at System.Windows.Forms.BindingSource.OnListChanged (System.ComponentModel.ListChangedEventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.ResetBindings (Boolean metadataChanged) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.SetList (IList l) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.ResetList () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.BindingSource.set_DataSource (System.Object value) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.BindingSource:set_DataSource (object)
  at JDP.frmSettings.frmSettings_Load (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.OnLoad (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.OnLoadInternal (System.EventArgs e) [0x00000] in <filename unknown>:0
System.ObjectDisposedException: The object was used after being disposed.
  at System.Windows.Forms.Control.CreateHandle () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.CreateHandle () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.get_Handle () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:get_Handle ()
  at System.Windows.Forms.Application.RunLoop (Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Form.ShowDialog (IWin32Window owner) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Form:ShowDialog (System.Windows.Forms.IWin32Window)
  at JDP.frmCUETools.toolStripButtonSettings_Click (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripButton.OnClick (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripItem.HandleClick (System.EventArgs e) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs e, ToolStripItemEventType met) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem:FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType)
  at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs mea) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0
  at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x00000] in <filename unknown>:0
and the attached image is the error i get when i try to get cuetools to output wav (image+cue and individual tracks give same error)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Shinji-kun on 2010-11-22 17:04:54
I have various soundtrack CDs ripped to single FLAC files with accompanying .CUE files. I want to split the single FLAC's and extract the individual track files.

I go into the file browser, select the desired .cue file, click "go" and then I get the following error, "Exception: ffmpeg: The system cannot find the file specified".

I have the .cue file of the single FLAC file that I want to split in the same folder as the FLAC.

Settings:

Action- Encode

Audio output- Lossless, m4a, ffmpeg alac

CUE Style- Tracks

Freedb lookup- if needed.


I am using CUETools v2.0.3.

My question is, why is this error occurring and how can I successfully split the single FLAC files into individual track files?

Any help appreciated.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: necropimp on 2010-11-23 18:17:19
more info on the error i get when encoding... it apparently only happens when a log file is present
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Bellum on 2010-11-24 17:55:26
Settings:
Audio output- Lossless, m4a, ffmpeg alac

I am using CUETools v2.0.3.

My question is, why is this error occurring and how can I successfully split the single FLAC files into individual track files?

Any help appreciated.


Just think you have a corrupted @ffmpeg alac@ one. Try to update CUETools (2.0.9 is available) and use libALAC instead of @ffmpeg alac@ (with default compression)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2010-12-06 18:23:14
There is some weird behavior when unicode filenames are involved.
My current settings are to set a file according to this pattern: %music%\_transcoding\'['Album']' %artist% - %album%.cue
Everything works fine as long as the filename stays alphanumeric. But when I have an utf-8.cue file, with Japanese kanji in tags for example, they will be substituted with underscores (_)

The reason  I never noticed it was because I usually have my codepage set to Japanese, so I assumed CUETools writes utf-8 filenames - obviously, it doesn't, which is rather weird since it doesn't have any issues with utf-8 anywhere else.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rjalex on 2010-12-08 16:51:43
Sorry to ask something stupid but despite Googling cannot find an answer.
Would be especially interested in the first two use cases described here (http://wiki.hydrogenaudio.org/index.php?title=CueTools#Use_cases)
Is there a Guide to this tool ?
I have ripped several CDs with EAC but mistakenly to a single FLAC file + CUE, as it takes more than hour for CD I'd love to use the CUE to help generate one FLAC per track possibly without re-encoding. Managed to do it with foobar but understand it's possible with CUETools too. Using Win XP and Win7. Any help please ?
Thank you in advance
Bob
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Saxo on 2010-12-09 12:11:22
Sorry to ask something stupid but despite Googling cannot find an answer.
Would be especially interested in the first two use cases described here (http://wiki.hydrogenaudio.org/index.php?title=CueTools#Use_cases)
Is there a Guide to this tool ?
I have ripped several CDs with EAC but mistakenly to a single FLAC file + CUE, as it takes more than hour for CD I'd love to use the CUE to help generate one FLAC per track possibly without re-encoding. Managed to do it with foobar but understand it's possible with CUETools too. Using Win XP and Win7. Any help please ?
Thank you in advance
Bob


It's easy in fact. But I understand, CUETools has a confusing GUI at first glance. You just choose “Encode” in the “Action” section, and then “Tracks” in the “Mode” section. On the section just above these two previous one, you can chose the path of the folder that contains all your cue/FLAC you want to convert for the “Input”, and CUETools will make a batch convert. I recommend you to choose the following template as an Output:

[%directoryname%\]%filename%-new[%unique%].cue

I hope that will help
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2010-12-10 20:55:40
A very small question: how could I use FLACCL in CUETools? I downloaded flaccl03.rar, but I'm still getting errors...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: osaldus on 2010-12-14 15:39:07
Can someone show me a script for
1. encode into file-new.flac
2. removing original files if the encoding is successful
3. rename file-new into original file

All I want to do actually is to use the magnificent CUE embedding capabilities of CUETools on a batch of folders. It would be perfect if not even encoding would be required, but given today's FLAC speed its not that bad.


At present time the only workaround for such a thing is to do a batch encoding on a different drive, however this does not copy the coverart usually located in the same folder as the flac.
A solution for this will be nice.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radivx on 2010-12-14 17:55:50
Hi
Which foobar2000 naming tags are implemented?
Tried to use $lowercase without any success.

Also are there any information on how to set up a cuetools development environment?
The current SVN version is not compiling out of the box
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: osaldus on 2010-12-16 11:36:26
This happened today.
Until yesterday, doing a batch conversion, dropping the root path on the "input", caused CueTools 2.09 to look first at the cuesheet, then encoding.
Now it looks first to the embedded cue in the flac file.
This is quite problematic in you're correcting by hand then reencode a flac with the corrected infos.
The "Setting/Tagging" has the Write basic tags from cue data" and "copy basic tags"active.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Multivsys on 2010-12-18 23:23:39
Greetings,

I'm trying to convert a large .tta file into multiple .flac files with included .cue file via CUETools 2.0.9. Unfortunately, even after installing Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update, I still received the error:

Exception: Unsupported audio type: G:\IMAE-00034.tta

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Guiny on 2011-01-06 08:27:28
Is there a way to either clear the profile or restore the default settings? I.e. run the program as if I was running it for the first time?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Merlin_de on 2011-01-06 18:36:17
hello,
i use 2.0.9. inside the german translate dll is a bug. i get always exeption and crash / or freeze if freedb or other other db provider is selectet.
the en and ru interface work without exeption. only the de interface has this bug since some version.
maybe there was some  missing (unsupportet) stuff inside de interface?

can this be fixed ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2011-01-06 18:41:31
I (as the German translator) don't really have any influence on the DLL itself, I only translate the strings without compiling it myself. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shanahan on 2011-01-08 15:54:19
CUETools:
Is it possible to access the network folder? how?
For example: input: "//network folder/Billy Idol - Greatest hits/Greatest hits.cue"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-01-08 18:10:16
Semi-educated guess: The "German" issue could be about locale conventions? Like comma vs full stop for decimal separator, etc?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2011-01-11 14:17:50
CUETools:
Is it possible to access the network folder? how?
For example: input: "//network folder/Billy Idol - Greatest hits/Greatest hits.cue"

Don't know, give it a try. Mapping the network folder to a drive letter has worked for me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: porty on 2011-01-14 11:24:12
Apologies if my question has been asked before...

The following log excerpts are results from when I ran CUETools>>>Verify on my albums folder.
Is there a problem with Album 1 and 2 since the first section has a status of "no match"?
All my other albums have a status of "accurately ripped" for all sections.

Could someone please help me understand whats happened?

Thank you.


Album 1
Code: [Select]
Track   [ CRC    ] Status
01     [db6e4999] (0/5) No match
02     [6c22543c] (0/5) No match
03     [ddd11b31] (0/5) No match
04     [ab2cbb3b] (0/5) No match
05     [d58296de] (0/5) No match
06     [eb622cc2] (0/5) No match
07     [7f4fa38c] (0/5) No match
08     [279f2576] (0/5) No match
09     [80bd3c87] (0/5) No match
10     [593db50c] (0/5) No match
11     [a96c781a] (0/5) No match
12     [f9075843] (2/7) Accurately ripped
Offsetted by 670:
01     [b75965e7] (5/5) Accurately ripped
02     [92eef4bc] (5/5) Accurately ripped
03     [a81fb869] (5/5) Accurately ripped
04     [8df62945] (5/5) Accurately ripped
05     [a20ff34a] (5/5) Accurately ripped
06     [a316230e] (5/5) Accurately ripped
07     [e69a85c8] (5/5) Accurately ripped
08     [6a1b6e48] (5/5) Accurately ripped
09     [9c7c2da7] (5/5) Accurately ripped
10     [6e286a58] (5/5) Accurately ripped
11     [90d76288] (5/5) Accurately ripped
12     [29b32909] (5/7) Accurately ripped



Album 2
Code: [Select]
Track   [ CRC    ] Status
01     [18fa5268] (000/152) No match
02     [8296adbc] (000/148) No match
03     [76e27ea3] (000/153) No match
04     [f3ae4341] (000/150) No match
05     [1a330e62] (000/148) No match
06     [b5ea5157] (000/152) No match
07     [cf378241] (000/152) No match
08     [9cabf414] (000/149) No match
09     [e0251af0] (000/150) No match
10     [2174fedb] (000/149) No match
11     [409c7127] (000/152) No match
12     [b798463e] (000/148) No match
Offsetted by -1280:
01     [9cd4f063] (004/152) Accurately ripped
02     [94374d73] (004/148) Accurately ripped
03     [330987e2] (004/153) Accurately ripped
04     [83dfdfa0] (004/150) Accurately ripped
05     [7f12dbb1] (004/148) Accurately ripped
06     [a0663589] (004/152) Accurately ripped
07     [db082127] (004/152) Accurately ripped
08     [60bdc039] (004/149) Accurately ripped
09     [16fa05ce] (004/150) Accurately ripped
10     [54ff804a] (004/149) Accurately ripped
11     [f1ff2819] (004/152) Accurately ripped
12     [aa60f733] (004/148) Accurately ripped
Offsetted by 30:
01     [a3972bc4] (140/152) Accurately ripped
02     [243a4ef0] (138/148) Accurately ripped
03     [3c2d3bab] (141/153) Accurately ripped
04     [17bdb9f7] (138/150) Accurately ripped
05     [ca27b5c5] (136/148) Accurately ripped
06     [fa709264] (140/152) Accurately ripped
07     [dc23711c] (140/152) Accurately ripped
08     [5be50a7e] (137/149) Accurately ripped
09     [ec82adba] (137/150) Accurately ripped
10     [d994a872] (136/149) Accurately ripped
11     [a7448cb6] (139/152) Accurately ripped
12     [94e118ab] (135/148) Accurately ripped
Offsetted by 36:
01     [805533b7] (002/152) Accurately ripped
02     [4e3b6cd8] (002/148) Accurately ripped
03     [26b866c8] (002/153) Accurately ripped
04     [b8f9d0a9] (002/150) Accurately ripped
05     [4c5c50d4] (002/148) Accurately ripped
06     [739e8649] (002/152) Accurately ripped
07     [a527ab84] (002/152) Accurately ripped
08     [11f918f9] (002/149) Accurately ripped
09     [b5a619ae] (003/150) Accurately ripped
10     [2c8e2e44] (003/149) Accurately ripped
11     [c4a4515f] (003/152) Accurately ripped
12     [7cf5fd43] (003/148) Accurately ripped
Offsetted by -634:
01     [9690bd2c] (002/152) Accurately ripped
02     [18a3d5ba] (000/148) No match
03     [a47dad5f] (002/153) Accurately ripped
04     [ce0b1661] (002/150) Accurately ripped
05     [dc6588be] (002/148) Accurately ripped
06     [193fc607] (002/152) Accurately ripped
07     [4172b7a8] (002/152) Accurately ripped
08     [0429e2cb] (002/149) Accurately ripped
09     [c55d0aca] (002/150) Accurately ripped
10     [0af34285] (002/149) Accurately ripped
11     [022cdf52] (002/152) Accurately ripped
12     [59dd09fb] (002/148) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-01-14 12:15:16
The 2 rips are accurate, if you fixed the offset while ripping (judging from rip 1, it seems to be the case) then you just happen to have a slightly different pressing that only differs by offset (small shift within the same audio data)

Quote
Apologies if my question has been asked before...

It have been asked zillion times before ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: maikeskidi on 2011-01-16 17:21:17
A very small question: how could I use FLACCL in CUETools? I downloaded flaccl03.rar, but I'm still getting errors...


I'd the same problem with CueTools 2.0.9 and solved it by putting the right file in the right folder.
It must be :

root folder :
CUETools.Codecs.dll
CUETools.FLACCL.cmd.exe
OpenCLNet.dll

plugins folder :
CUETools.Codecs.FLACCL.dll
CUETools.Codecs.FLAKE.dll
flac.cl

overwrite existing file.
CUETools should propose you the FLACCL encoder with flac format.

My video card is an ATI Radeon HD5450 with 10.12 drivers (Stream - APP included) and I saw (with GPU-Z) the GPU load about 40% while encoding.
I'm just disappointed to see no reduction of the overall time for encoding.
It took 5 min 20 sec to encode "Portishead - Roseland NYC Live" with Libflake and FLACCL (compression ratio of 8 for both).

I hope I'm not off-topic but , does any one els observed better results with FLACCL 0.3 on ATI video cards ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2011-01-17 02:50:16
Request:

Add a "No to all" option for the following dialogue:

One or more output files already exists, do you want to overwrite?


I am trying to verify and submit my collection. Unfortunately it has crashed a couple of times. This means when I go back and try to re-verify, many of the albums already have output files and have been submitted to CTDB. I have to either let CT re-verify all of my files or manually skip the 1000s already done.


Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-01-17 20:37:27
I always used CUETools in English and got no errors.
Now I have installed it on a notebook with German Windows version and left the UI as is (german).
Indeed, the out-of-array error occurs if any of both internet databases is selected.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-01-22 22:41:46
My video card is an ATI Radeon HD5450 with 10.12 drivers (Stream - APP included) and I saw (with GPU-Z) the GPU load about 40% while encoding.
I'm just disappointed to see no reduction of the overall time for encoding.
It took 5 min 20 sec to encode "Portishead - Roseland NYC Live" with Libflake and FLACCL (compression ratio of 8 for both).

I hope I'm not off-topic but , does any one els observed better results with FLACCL 0.3 on ATI video cards ?


Thank you for your help, now I can use flaccl from CUETools.

I've made a test conversion from a single flac image into flac tracks and I was really impressed!
Instead about 40x using libflac  I got 100-140x ;-)

My video card is ATI Radeon 5870.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2011-01-23 22:06:28
Indeed, the out-of-array error occurs if any of both internet databases is selected.

Actually, that is independent of that selection, whyever,,,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Manlord on 2011-02-05 21:42:14
Why does CUETools name HTOA as:
    01.00 (HTOA).*

Wouldn't it be more natural to name them as:
    00. (HTOA).* or similar


Thanks again for this awesome tool.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2011-02-08 21:38:04
I have been successfully using the pregaps script until today. Now when I execute it gives the following error:

[clipped]\EC2.tmp(2,24): error CS0117: 'CUETools.AccurateRip.AccurateRipVerify' does not contain a definition for 'AccResult'
[clipped]\EC2.tmp(10,24): error CS0117: 'CUETools.AccurateRip.AccurateRipVerify' does not contain a definition for 'AccResult'

Does anyone have any idea why this is happening ? Thank you

Code: [Select]
if (processor.ArVerify.AccResult == HttpStatusCode.OK)
return processor.Go();
if (processor.PreGapLength != 0)
return processor.WriteReport();;
foreach (uint gap in new uint[5] {1, 32, 33, 37, 42})
{
processor.PreGapLength = gap;
processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
if (processor.ArVerify.AccResult == HttpStatusCode.OK)
return processor.Go();
}
return processor.WriteReport();
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ustas on 2011-02-20 08:45:33
I found bug in CueTools 2.0.9 and diacritics symbols. When programm workin in CUE sheer creator mode, and a file name has diacritics, in CUE created by programm diactrics not displayed. Instead of diactric "i" displayed character "?"
example:
FILE "Catherine Br?tt - Too Far Gone - 03 - Too Far Gone.ape" WAVE
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jaro1 on 2011-02-20 10:29:07
Does this exception mean something related to one specific thing or could it appear in more cases?

Exception: crc.Combine length cannot be negative
Parameter name: len2
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2011-02-25 10:15:01
Does this exception mean something related to one specific thing or could it appear in more cases?

Exception: crc.Combine length cannot be negative
Parameter name: len2

I second this. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Helios61 on 2011-02-27 20:30:59
Hi community!

I use cuetools to split my img/cuesheets into seperate flac files! Often the result is a not workink cuesheet!

Sample cuesheet before split:
Code: [Select]
REM GENRE Klassik
REM DATE 2009
REM DISCID 7A12340A
REM COMMENT "ExactAudioCopy v0.99pb4"
SONGWRITER "Felix Mendelssohn Bartholdy"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig;Kurt Masur;Lynn Harrell;André Previn"
TITLE "Mendelssohn"
FILE "01 - Anne-Sophie Mutter - Mendelssohn.wv" WAVE
  TRACK 01 AUDIO
TITLE "Violin Concerto in E Minor, Op.64 - Allegro molto appassionato"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig, Kurt Masur"
INDEX 01 00:00:00
  TRACK 02 AUDIO
TITLE "Violin Concerto in E Minor, Op.64 - Andante"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig, Kurt Masur"
INDEX 01 12:19:26
  TRACK 03 AUDIO
TITLE "Violin Concerto in E Minor, Op.64 - Allegro molto vivace"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig, Kurt Masur"
INDEX 00 19:34:15
INDEX 01 19:34:16
  TRACK 04 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Molto allegro agitato"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 00 25:49:06
INDEX 01 25:51:09
  TRACK 05 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Andante con moto tranquillo"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 01 34:52:21
  TRACK 06 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Scherzo: Leggiero e vivace"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 01 41:44:28
  TRACK 07 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Finale: Allegro assai appassionato"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 01 45:22:62
  TRACK 08 AUDIO
TITLE "Violin Sonata in F Major (1838) - Allegro vivace"
PERFORMER "Anne-Sophie Mutter;André Previn"
INDEX 00 53:33:35
INDEX 01 53:38:74
  TRACK 09 AUDIO
TITLE "Violin Sonata in F Major (1838) - Adagio"
PERFORMER "Anne-Sophie Mutter;André Previn"
INDEX 01 65:04:24
  TRACK 10 AUDIO
TITLE "Violin Sonata in F Major (1838) - Assai vivace"
PERFORMER "Anne-Sophie Mutter;André Previn"
INDEX 01 72:18:14

Sample cuesheet after split: 
Code: [Select]
REM ACCURATERIPID 001ecacd-00f1cf4d-7a12340a
REM GENRE "Klassik"
REM DATE 2009
REM DISCID 7A12340A
REM COMMENT "ExactAudioCopy v0.99pb4"
SONGWRITER "Felix Mendelssohn Bartholdy"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig;Kurt Masur;Lynn Harrell;André Previn"
TITLE "Mendelssohn"
FILE "01 - Violin Concerto in E Minor, Op.64 - Allegro molto appassionato.flac" WAVE
  TRACK 01 AUDIO
TITLE "Violin Concerto in E Minor, Op.64 - Allegro molto appassionato"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig, Kurt Masur"
INDEX 01 00:00:00
FILE "02 - Violin Concerto in E Minor, Op.64 - Andante.flac" WAVE
  TRACK 02 AUDIO
TITLE "Violin Concerto in E Minor, Op.64 - Andante"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig, Kurt Masur"
INDEX 01 00:00:00
  TRACK 03 AUDIO
TITLE "Violin Concerto in E Minor, Op.64 - Allegro molto Vivace"
PERFORMER "Anne-Sophie Mutter;Gewandhausorchester Leipzig, Kurt Masur"
INDEX 00 07:14:64
FILE "03 - Violin Concerto in E Minor, Op.64 - Allegro molto Vivace.flac" WAVE
INDEX 01 00:00:00
  TRACK 04 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Molto allegro agitato"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 00 06:14:65
FILE "04 - Piano Trio No. 1 in D Minor, Op.49 - Molto allegro agitato.flac" WAVE
INDEX 01 00:00:00
FILE "05 - Piano Trio No. 1 in D Minor, Op.49 - Andante con moto tranquillo.flac" WAVE
  TRACK 05 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Andante con moto tranquillo"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 01 00:00:00
FILE "06 - Piano Trio No. 1 in D Minor, Op.49 - Scherzo_ Leggiero e vivace.flac" WAVE
  TRACK 06 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Scherzo: Leggiero e vivace"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 01 00:00:00
FILE "07 - Piano Trio No. 1 in D Minor, Op.49 - Finale_ Allegro assai appassionato.flac" WAVE
  TRACK 07 AUDIO
TITLE "Piano Trio No. 1 in D Minor, Op.49 - Finale: Allegro assai appassionato"
PERFORMER "Anne-Sophie Mutter;Lynn Harrell;André Previn"
INDEX 01 00:00:00
  TRACK 08 AUDIO
TITLE "Violin Sonata in F Major (1838) - Allegro vivace"
PERFORMER "Anne-Sophie Mutter;André Previn"
INDEX 00 08:10:48
FILE "08 - Violin Sonata in F Major (1838) - Allegro vivace.flac" WAVE
INDEX 01 00:00:00
FILE "09 - Violin Sonata in F Major (1838) - Adagio.flac" WAVE
  TRACK 09 AUDIO
TITLE "Violin Sonata in F Major (1838) - Adagio"
PERFORMER "Anne-Sophie Mutter;André Previn"
INDEX 01 00:00:00
FILE "10 - Violin Sonata in F Major (1838) - Assai vivace.flac" WAVE
  TRACK 10 AUDIO
TITLE "Violin Sonata in F Major (1838) - Assai vivace"
PERFORMER "Anne-Sophie Mutter;André Previn"
INDEX 01 00:00:00
Could you please tell, what am i doing wrong? Sorry for my poor english!

Best regards

H
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Not One Of Us on 2011-03-06 11:49:01
Trying to encode a .tta to separate FLAC tracks, and getting this error:

Exception: First index must start at file beginning.

After some searching around, what I think it's complaining about is the first track in the .cue starts at 00:02:00.  I try to adjust this manually in the pregap and it gives me the same error.  Any ideas?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-06 11:59:38
I already had this error, with a single file CDImage.cue I added INDEX 00 00:00:00 before INDEX 01, which means like you said that I manually added the pregap & it solved my problem. I don't know what you did exactly but it seems to me that you wanted to do the right correction but you just did it wrong.

Edit: As far as I understund your cue should begin like this:
INDEX 00 00:00:00
INDEX 01 00:02:00

This kind of rips seems to miss all INDEX 00, I dunno why.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-06 13:48:08
By the way, can someone tell me how to use the 32, 33, 37 pregap script from this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=725&p=670553&#entry670553), I tried to copy/paste this in setting/script, but I cannot paste anything (or untick any radio button), I tried to search in the appz directories in case I found something that would look like a text file with scripts in it but I didn't found any, so how does script work ? where should I put this script ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2011-03-06 14:36:07
hi sauvage78,

you can edit settings.txt in %appdata%\CUE Tools (alternate %ProgramFiles%\CUETools).
Search for CustomScripts=6. Change to CustomScripts=7 (6+1).

Add these lines

Code: [Select]
CustomScript6Name=YOURNAME
CustomScript6Code=
YOUR SCRIPT
CustomScript6Condition0=1
CustomScript6Conditions=1


Replace 6 by whatever number you find in your file.

Cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-06 14:59:26
Ok thks for trying to help, I tried with this but it crashed.

Line just before:
CustomScript5Conditions=1

Code: [Select]
CustomScripts=7
CustomScript7Name=Test Gaps
CustomScript7Code=if (processor.ArVerify.AccResult == HttpStatusCode.OK)
return processor.Go();
if (processor.PreGapLength != 0)
return processor.WriteReport();;
foreach (uint gap in new uint[3] {32, 33, 37})
{
processor.PreGapLength = gap;
processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
if (processor.ArVerify.AccResult == HttpStatusCode.OK)
return processor.Go();
}
return processor.WriteReport();
CustomScript7Condition0=1
CustomScript7Conditions=1

Line just after:
DefaultVerifyScript=default

Quickly looking at others scripts it seems I am missing plenty of = at the beginning of each line in CustomScript7Code=
I will try to fix that & see if it works if I can understand the syntax.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2011-03-06 15:11:48
It should be:

Line just before:
CustomScript5Conditions=1

Code: [Select]
CustomScript6Name=Test Gaps
CustomScript6Code=if (processor.ArVerify.AccResult == HttpStatusCode.OK)
return processor.Go();
if (processor.PreGapLength != 0)
return processor.WriteReport();;
foreach (uint gap in new uint[3] {32, 33, 37})
{
processor.PreGapLength = gap;
processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
if (processor.ArVerify.AccResult == HttpStatusCode.OK)
return processor.Go();
}
return processor.WriteReport();
CustomScript6Condition0=1
CustomScript6Conditions=1
CustomScripts=7



Line just after:
DefaultVerifyScript=default
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-06 15:28:06
Thks now cuetools doesn't crash at startup & I can see the script under the "verify" option, but now I have a new problem:
when I try to test files I get

filepath+
c:\Users\username\AppData\Local\Temp\CSSCRIPT\B2E5.tmp(3,2): error CS1525: Terme d'expression non valide '}'
c:\Users\username\AppData\Local\Temp\CSSCRIPT\B2E5.tmp(3,5): error CS1002: ; attendu

in the bachlog, it's in french but "Terme d'expression non valide" means something like "Invalid expression term" & "attendu" means "expected".

Seems like there is a problem with } maybe as } is the only character in some line of the script (just guessing).

Edit: I have the same error when I push the "compile" button in settings/scripts
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2011-03-06 16:10:19
Now that you see your script under verify you can edit it under the "scripts" tab of the advanced settings of cuetools.
Click on your script name and try copying the code from the original post and compiling it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-06 16:19:17
When I add = before each of the CustomScript6Code= line or when I copy paste the original script in settings/scripts (which is now editable) & try to push the "compile" button, now I get:

filepath+
c:\Users\username\AppData\Local\Temp\CSSCRIPT\33C1.tmp(2,24): error CS0117: 'CUETools.AccurateRip.AccurateRipVerify' ne contient pas de définition pour 'AccResult'
c:\Users\username\AppData\Local\Temp\CSSCRIPT\33C1.tmp(10,24): error CS0117: 'CUETools.AccurateRip.AccurateRipVerify' ne contient pas de définition pour 'AccResult'

"ne contient pas de définition pour 'AccResult'"="contains no definition for 'AccResult'""

It seems I progress ... slowly.

I am using this now:

Line just before:
CustomScript5Conditions=1

Code: [Select]
CustomScript6Name=Test Pregap
CustomScript6Code=if (processor.ArVerify.AccResult == HttpStatusCode.OK)
=return processor.Go();
=if (processor.PreGapLength != 0)
=return processor.WriteReport();;
=foreach (uint gap in new uint[3] {32, 33, 37})
={
=processor.PreGapLength = gap;
=processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
=if (processor.ArVerify.AccResult == HttpStatusCode.OK)
=return processor.Go();
=}
=return processor.WriteReport();
CustomScript6Condition0=1
CustomScript6Conditions=1
CustomScripts=7


Line just after:
DefaultVerifyScript=default
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2011-03-06 17:04:00
OK, so now you are getting the same errors I reported earlier on the thread.
I dont know the reason for those errors, they are probably related to .NET 4.0.
Try this code instead, it works for me:

Code: [Select]
if (processor.PreGapLength != 0)
return processor.WriteReport();;
foreach (uint gap in new uint[3] {32, 33, 37})
{
processor.PreGapLength = gap;
processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
}
return processor.WriteReport();
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-06 17:35:10
Ok now it seems to work as there is no error when I compile or run it with your code.

But the code itself doesn't seem to do what I expected from it, I expected it to test with pregap 0, 32, 33, 37 so I tested with rips which have a pregap 32/33 & which I know are all in AR database & the result was not find in database with a pregap 37 in log & only 1 line by rip in bachlog. So it seems it only tested pregap 37 & didn't found anything (which is normal as those rips are pregap 32/33).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Not One Of Us on 2011-03-06 19:37:04
I already had this error, with a single file CDImage.cue I added INDEX 00 00:00:00 before INDEX 01, which means like you said that I manually added the pregap & it solved my problem. I don't know what you did exactly but it seems to me that you wanted to do the right correction but you just did it wrong.


Yeah, that's how I ended up "fixing" it.  Of course, that adds two extra seconds of silence to the track, but whatever.  I was hoping there'd be a more...standard way to solve the problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-07 02:19:15
I finally found the time to publish a new version.

The main new feature is local database, which stores verification results and metadata.

Here are some tips on how to use it to e.g. compare duplicate rips and different pressings:

* Disable "Write AccurateRip log" and "Write AccurateRip tags" in advanced options, you don't need them if you use the database.
* In Folder Browser, right-click on the folder with your rips and choose "Add folder to local database".
* Switch from Folder browser to Local database view.
* Under "By Uniqueness" select "Not yet verified clones" and batch-verify them.
* Press F5 to refresh Local database view
* Explore results.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jaro1 on 2011-03-07 09:49:13
wow, thank you very much!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-07 13:21:04
Quote
* Added 'Silent track' diagnostics in AR log


[00000000] (0/0) Silent track = CDImage.cue: AR: rip not accurate

Reporting [00000000] as Silent track is ok, but it's useless if the bachlog still report "rip not accurate" just because of a silent track.

The problem was with the bachlog which gives you a false report, not with the .accurip log. I still have to sort my rip with [00000000] in a separate folder if I don't want them to be mixed with rips which are really not accurate, so it's more self-speaking for new users but it's useless for me.

That was just my very first impression. I am still trying to understand what is that green puzzle icon (seems it's a local database that recall what you already tested, right?) & that clock icon (no clue). It's likely that I will complain some more soon
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-07 13:31:26
Waiting with anticipation for your complaints 

Yep, the green puzzle icon means local database, which stores your logs for you and lets you browse verified library in certain useful ways.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-07 14:12:47
At first I was septikal about this database thing but I like the local database ability to automatically find dupe & not accurate & AR(1) rips, if I can use it as I like, it will be a time saver for me.

So my first question is how do I nuke the database ? cauz as of my actual understanding of how it works I will only use it to sort my folders by AR results after each verification pass. So I don't need it to contain all my past verifications results unless I can sort by multi-criteria, like first by date of verification & then by AR results. It seems actually it's sorted by one or the other but not both, hence the reason why I think I will need to nuke the database regulary.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-07 17:51:17
A bug that is not specific to the new version, but that I don't recall I reported so far: often the information bar at the buttom is completely blackened except the green progress bar. I dunno why it happens but it may be linked to how the window is resized/reduced/enlarged as it happens often (more than 50% of time) but not at startup IIRC, maybe it is also linked to the fact that I use 125% fonts, I dunno. (I use Win7 32bits SP1)

A screenshot of the bug:
(http://img534.imageshack.us/img534/2310/pressepapier01.png) (http://img534.imageshack.us/i/pressepapier01.png/)

Edit1:
Also if the new local database is going to be used as a way to automatically sort the batchlog, it would be interesting to have a NPID (not present in database) entry in Localdatabase/Sort by Accuraterip Confidence, because without this I will still have to copy/paste the batchlog in a .txt & search within it manually.
So IMHO it's either all or nothing, the localdatabase must completely take over the batchlog without leaving result outside, even if not in database.

The idea of a local database is good but personnaly I quickly started to think that it should completely replace the batchlog if done correctly.

Edit2:
This is just my personnal opinion but if I were to sort result according to AR, I would sort it like that:

AR(1)
AR(2)-AR(10)
AR(10+)
nAR-NM (not accurate with only "no match", reasonnable probability of being incomplete in database without being necessarily scratched)
nAR-NMBO (not accurate with "no match but offset", high probability of being scratched)
NPID (Not present in database)

+ special categories for
Silent Track [00000000]
Data Track (ECD)
CDDBId Mismatch
Doublons

Actually I think the difference between the AR(2), AR(3) & AR(below 5) categories is meaningless, as well as the difference between the AR(below 10) & AR(below 20) categories.
It's way too much categories for me, personnaly I only need two: AR(with low confidence) & AR(with high confidence). My personnal limit between high & low is AR(10) & it is completely arbitrary.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-07 18:53:51
I cannot edit anymore  & I am not sure that the word "categorie" exist in english so plz read: categorie=class

Edit: Thks Greynol.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-03-07 18:56:22
Category is the correct singular form of the plural word categories.

I can understand why this might be difficult for a non-native English speaker.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-07 20:42:17
Another bug that is not specific to the last version, when you use the Windows Snap feature from Windows 7 which automatically resize a window to half the size of your screen in order that you can see two windows on your screen (left/right), cuetools is always resized a little larger than half the screen which is annoying.

Bug screenshot:
(http://img834.imageshack.us/img834/2310/pressepapier01.png) (http://img834.imageshack.us/i/pressepapier01.png/)

I report it now because with the new local database it is easy now to browse the local database on the left window & sort your folders according to the results of the database on the right window, so it is more annoying now than it was previously.

Also as a suggestion, adding in parenthesis the sum of the number of rips in each category & each sub-category would maybe be interesting.

Edit:
I wanted to underline that the fact that you left out "not present in database" results from the local database as the side effect that finding dupes within rips that are not in AR database doesn't work, while I think technically CT could be used to find dupes within those rips, even just by comparing CTDB TOCID, if sums are not calculated (when using "verify only if found").
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jaro1 on 2011-03-08 11:02:40
I still don't understand, how CUERipper handles C2 pointers. I didn't find any settings or options related to CUERipper. Doesn't matter if Burst or Secure mode is used, in final log, there is always  Make use of C2 pointers : No, though according to Gregory (http://wiki.hydrogenaudio.org/index.php?title=Comparison_of_CD_rippers) it is supported.
Second, i've total chaos from many explanations related to defeating cache with or without FUA support, they are offen contradictory. I suppose, CUERipper doesn't have FUA implemented, maybe in the future, or it isn't necessary at all (of course it must be firstly supported by the drive itself).

Simply i'm interested how CUERipper works, because objectivelly in my case (W7 x32, LG 4167B) it gives me consistently the most correct results from the other two well known rippers (EAC, dBP Ripper, with all ripping modes checked out). Tested on o scratched CDs and compared with the rips from other drive that was able to read them without a single problem, the possible reported suspicious positions on LG were in the case of CUERipper always correct (amount and position), unlike the other two (e.g. EAC, in Burst mode or Secure mode with (here it could be obvious) but also without C2). Moreover, CUETools was able to repair CUERipper rips into AR compliant state, perfect.

I appreciate Gregory's good work here, because it is the only ripper that could pull from my old drive really maximum, in that it can correctly interprete the readed samples. interesting if also others with relatively older drives, have a similar experience.
I use CUERipper mostly in Burst mode, according to log no C2s are used. When are they in use, if at all?. So how it is?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2011-03-08 11:12:22
On start, a message "CUETools 2.0.9 is out!" appears.
Is the bug with the de-DE.dll fixed BTW?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 14:34:40
I still don't understand, how CUERipper handles C2 pointers.

It does use C2 pointers even in burst mode, if the drive supports them.

But not in the same sense that EAC does. I'm speculating here, because EAC is not open source and i can only repeat what i've read about it on some forum, but it seems that EACs "Use C2 pointers" option can decrease the number of retries the ripper makes if the drive reports that data is ok (correct me if i'm wrong), while CUERipper only uses C2 to increase the number of retries if the drive reports that data is not ok. In other words, CUERipper uses C2 pointers while EAC relies on C2 pointers.

Second, i've total chaos from many explanations related to defeating cache with or without FUA support, they are offen contradictory. I suppose, CUERipper doesn't have FUA implemented, maybe in the future, or it isn't necessary at all (of course it must be firstly supported by the drive itself).

CUERipper doesn't use FUA bit, but instead works under assumption that drive has no more than 8 megabytes of cache, and invalidates this cache in only reliable way - by reading in large non-overlapping chunks, which forces the cache invalidation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 14:49:56
On start, a message "CUETools 2.0.9 is out!" appears.
Is the bug with the de-DE.dll fixed BTW?

That message will probably go away soon. It is cached for one day. You downloaded new version before CUETools found out there's a new version
Thank you for reminding me, I just fixed the crash with de-DE locale. Just download it again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 14:55:27
I wanted to underline that the fact that you left out "not present in database" results from the local database as the side effect that finding dupes within rips that are not in AR database doesn't work, while I think technically CT could be used to find dupes within those rips, even just by comparing CTDB TOCID, if sums are not calculated (when using "verify only if found").

Rips that aren't in AR database still go to local database. If you use "Add folder to local database", AR is not contacted at all. And dupes are also found regardless of AR, just make sure you are not verifying in "only if found" mode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 15:02:27
So my first question is how do I nuke the database ?

Just delete the file "C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-08 15:11:08
Thks for answers. I am slowly starting to like this local database thing even if not perfect yet.

Quote
Just delete the file "C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z"

I had the idea but I was afraid to break something, it'll do the trick for now but I think a button within the GUI would be more practical in the future.

Quote
just make sure you are not verifying in "only if found" mode.

Well with my slow sempron 3000+ I was always using "only if found" mode so far, hence it didn't work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 15:20:26
Then use the method i described earlier to find dupes. It should be fast.

* In Folder Browser, right-click on the folder with your rips and choose "Add folder to local database".
* Under "By Uniqueness" select "Not yet verified clones" and batch-verify them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-08 15:49:58
Thks worked great, but what is this new CRC in batchlog, like:
Code: [Select]
cdimage.cue: CRC 2C2822C4

How is it calculated & what does it mean?

What is used to detect clones using this fast method, specially compared to a full scan with sums?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 15:55:39
That's CRC32 of the audio data without the few leading and trailing samples.
That's because drives with different offsets and no overread capability will produce different data in those areas.
Actually, several such CRCs with different offsets are stored in DB, which also allows to detect offset-corrected dupes or different pressings ("Offsetted clones" category)

Those CRCs are computed when verifying, so before verification DB doesn't know if the dupes have the same audio data, and places them in "Not yet verified clones" category.
Clones by definition are discs with the same DiscIds/TOCs (ignoring pregap/data track). Only DiscIds are calculated when adding folder to database without verification.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-08 16:12:19
So DiscIds/TOCs are not Edit:AccurateRip ID CTDB TOCID, which explains why it is faster than calculating audio data sums but slower than just comparing Edit:AccurateRip ID CTDB TOCID (which should be almost instant fast if it was already calculated in the .accurip)

As far as I understund it has the advantage of being able to find dupe between 2 identical rips with different Edit:AccurateRip ID CTDB TOCID due to a pregap/datatrack difference only, that's it? First pass DiscIds/TOCs (without pregap/datatrack), 2nd pass CRC32 (without leading & trailing samples) ... sounds very efficient.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 16:16:14
CTDB and local database have much in common. They both use two IDs - one for TOC, one for audio data. DiscID/TOCId is the same as in CTDB.  Data CRCs are slightly different, because when i was developing CTDB i didn't invent this new way of detecting offsets yet.

So you are mostly right, but dupes always have the same CTDB TOCID.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-08 16:23:39
Sounds like I am missing something there because I thought Edit:AccurateRip ID CTDB TOCID was calculated with pregap/datatrack & you tell me DiscIds/TOCs is not but at the same time that "DiscID is the same as in CTDB", so now I am lost within all these ID ... sorry if I am dumb.

Edit: Sorry I just realized I mixed AccurateRip ID with CTDB TOCID in post #1269, so now it's a mess, much sorry, I edited all that
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jaro1 on 2011-03-08 17:45:08
Quote
EACs "Use C2 pointers" option can decrease the number of retries the ripper makes if the drive reports that data is ok (correct me if i'm wrong), while CUERipper only uses C2 to increase the number of retries if the drive reports that data is not ok. In other words, CUERipper uses C2 pointers while EAC relies on C2 pointers.

You gave a little bit more light to that, however i still think "decreasing the number of retries if the drive reports that data is ok" and "increase the number of retries if the drive reports that data is not ok" are two different approaches but with the same resulting effect. EAC secure with C2 and CUERipper in burst mode, both will do multiple readings only if get error report from the drive, unless CUERipper in burst mode reads every chunk twice (from the speed indicator it doesn't seem so) , i don't think so, its the case only for secure mode.
Ah what, just doesn't matter, CUERipper simply works much better for me. 

Quote
drive has no more than 8 megabytes of cache, and invalidates this cache by reading in large non-overlapping chunks, which forces the cache invalidation.

At least i shouldn't buy a drive with bigger that 8MB cache, if i find one  anyway, a clever idea.
Thanks for explanation and hard work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-08 18:44:39
Quote
dupes always have the same CTDB TOCID

So CTDB TOCID from .accurip using "only if found" could be used to find possible dupe before further CRC examination, right ? It would be even faster than re-calculating DiscIds/TOCs, no ??? Not that I really care, the method you pointed me is already fast enougth anyway. I am just curious as is was the way I expected it to be done.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-08 20:03:04
So CTDB TOCID from .accurip using "only if found" could be used to find possible dupe before further CRC examination, right ? It would be even faster than re-calculating DiscIds/TOCs, no ???

If you already have the logs - in theory, yes. But CUETools doesn't parse logs when it creates the database. Logs are there only for your convenience. TOCs are calculated fast enough, because you only have to parse .cue file and look at the headers of audio files to find out their length. No audio is decompressed at this stage.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nowings69 on 2011-03-08 22:22:39
Thanks for 2.1.1
Accuracy,Flaccl#0.3 was very pickey to only my legacy Nvidia's GPU(9600GT)
but Flaccl#0.4 works fine
You are the superior developer for OpenCL as far as I know it 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-09 12:03:36
My guess is that you already intend to do it as it is an evidence, but sorting result in the local database according to CTDB would be usefull too, now the problem is how to sort rip that are OK & differs at the same time.

I think it can be done in 3 categories:
-CTDB NPID (Not Present in Database) ==> Unknown
-CTDB Present in Database (No Matter If OK or differs)+AR(No Matter Condidence) ==> Accurate So CTDB Is Likely Useless
-CTDB Present in Database (Differs)+Not Accurate ==> Likely Scratched & Fixable

Also you said you intended to add .toc support for ECD with old EAC log that don't include .toc & miss the datatrack length, did you ever wonder about supporting it in .cue sheet via the REM command, I mean if you parse a .cue for
REM COMMENT "CUETools CD-Extra data track length 09:26:06." or maybe just
REM DATA "CD-Extra data track length 09:26:06." (I prefer the second one as it is easier to edit)
It would do the trick IMHO.

I mean the pregap length & the track number (incl. the data track via the DISCID) are already in the cue sheet, so IMHO it's far from illogical to store it there.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: chapa on 2011-03-12 22:17:57
Gregory S. Chudov
Thanks for CUE Tools 2.1.1. This great prog is most helpful for me with .wv.

Vertical? She drowned.

We Shall Overcome!
Make Love, Not War.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-03-13 16:54:49
HDCD detection changes in 2.1.1? No longer seeing HDCD in Batch Log, AccurateRip Log and not in Local Database on rips where 2.0.9 detected HDCD.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-13 18:01:45
As a suggestion, as I don't merge my folder with AR(1) results with my folder with AR(>=2) results even if I have the CD, a script that would "test only if AR confidence is different from AR(1) in AR database" would be usefull for me. Just like "test only if found", it would be a CPU time saver for me as it would help skip AR(1) results when I re-test my folder with only AR(1) results. Doing so it would only test results which are not AR(1) anymore in AR database either because the result was dismissed: [AR(0) or "not present anymore in AR database"], or because it is now AR(>=2) [so I don't need to re-test them anytime soon]. Re-testing each months AR(1) results which are still AR(1) in database is a waste of ressource IMHO (specially with my weak CPU). I know some netpicking people might argue that re-testing AR(1) rip is useless if you have the CD anyway, thks I know it, keep your opinion cauz I'll keep mine & such a script would be usefull for me. (In ten years from now I don't know if I will still have the CD & I don't know if I will remember that I did have the CD one day for each of my rip, so like it or not, personnaly I never consider AR(1) safe)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-13 19:55:53
I confirm that CD previously detected as HDCD are not detected as HDCD anymore (Tested on 6 HDCD).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: GreenDrazi on 2011-03-15 06:08:28
Another item that seems to be missing in CUETools v2.1.1:

When verifying tracks that need an un-known pre-gap number, you now have to allow the program to proceed with verifying and overwriting an existing log file to know if the number you are trying is the correct number in the database. This is fine if you know the correct number.

Previously, you would get the request to overwrite the existing log file along with the Accuraterip icon highlighted to let you know that you’ve chosen the correct pre-gap number. If it wasn’t the correct pre-gap number, the Accuraterip icon was not highlighted and you could just select “no” to not over-write and move onto the next pre-gap number. This made it much quicker to get to a correct pre-gap number.

If there is a better way or quicker way to get correct pre-gap numbers, please let me know.


Otherwise, thanks for the update and a great program.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: amalone on 2011-03-15 06:53:20
I can convert Flac files to Ogg Vorbis image files with the track information embedded using Foobar2000. If I use CueTools, the track info is not there. Is it just command line parameters that need to be changed. If so, can someone tell me what they should be? With both Foobar and CueTools I am using the latest AoTuv encoder (6.02).

When ripping a CD to Flac with Foobar, I can easily delete tracks that I do not want included. I do not see an option in CueRipper to do this. Am I overlooking something?

Many thanks for this great software.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2011-03-15 15:54:25
Another item that seems to be missing in CUETools v2.1.1:

When verifying tracks that need an un-known pre-gap number, you now have to allow the program to proceed with verifying and overwriting an existing log file to know if the number you are trying is the correct number in the database. This is fine if you know the correct number.

Previously, you would get the request to overwrite the existing log file along with the Accuraterip icon highlighted to let you know that you’ve chosen the correct pre-gap number. If it wasn’t the correct pre-gap number, the Accuraterip icon was not highlighted and you could just select “no” to not over-write and move onto the next pre-gap number. This made it much quicker to get to a correct pre-gap number.

If there is a better way or quicker way to get correct pre-gap numbers, please let me know.


Otherwise, thanks for the update and a great program.


i think it worked better the old way too, it was a good way to check a few different possibilities quickly for older eac rips without gap detection. for what its worth though, if you press stop before the verification is completed the log doesnt appear to be overwritten.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2011-03-15 17:17:03
thanks for the update, im totally indebted to cuetools.. one quick question thats been bugging me if i may.. this one has been bugging me for a couple of days. here are two reports from the same rip, one with a cue file and one without. please note that one is "accurate" and one not, the crcs for track 1 have different values for the same track! is there a reason for this?

with cue

[CUETools log; Date: 15/03/2011 17:24:00; Version: 2.1.1]
Pregap length 00:00:33.
[CTDB TOCID: Vuf8OxYpGA1WPTZiSMPGXcsCza4-] found.
        [ CTDBID ] Status
        [79bc561b] (72/72) Accurately ripped
[AccurateRip ID: 000aae9c-00488545-69091008] found.
Track  [ CRC    ] Status
01    [7ff67560] (023/095) Accurately ripped
02    [53ff39a0] (026/099) Accurately ripped
03    [4269846f] (025/099) Accurately ripped
04    [e78babb6] (024/096) Accurately ripped
05    [63aa7ee4] (026/100) Accurately ripped
06    [d90c3a31] (025/098) Accurately ripped
07    [56ac3dc9] (024/097) Accurately ripped
08    [94e3cb88] (026/096) Accurately ripped
Offsetted by -1187:
01    [14e12e73] (012/095) Accurately ripped
02    [e348df57] (012/099) Accurately ripped
03    [a4e0fe5e] (013/099) Accurately ripped
04    [88c4099b] (013/096) Accurately ripped
05    [abb5dca8] (013/100) Accurately ripped
06    [88ac357e] (013/098) Accurately ripped
07    [076dfa13] (013/097) Accurately ripped
08    [97fe8420] (013/096) Accurately ripped

(edited)....

Track Peak [ CRC32  ] [W/O NULL]
--  93.8 [69D28992] [4F9382CA]         
01  87.9 [3A958896] [38EE23BC]         
02  93.8 [98852A53] [6F75C85C]         
03  91.7 [BAC2FC05] [76E8E3E3]         
04  64.7 [C8DC7D44] [3DCC4E18]         
05  87.6 [067ADAF0] [83DA9F5E]         
06  89.2 [5AD30B16] [B57A34EB]         
07  82.6 [FC1B168A] [D753063A]         
08  87.5 [468FAF05] [3EBF666F]         


without cue

[CUETools log; Date: 15/03/2011 16:51:34; Version: 2.1.1]
Pregap length 00:00:33.
Using preserved id, actual id is 000aafa4-00488af1-6c091108.
[CTDB TOCID: MIBr0Co..lcDgLO_bhdFOXYGGkw-] disk not present in database.
[AccurateRip ID: 000aae9c-00488545-69091008] found.
Track  [ CRC    ] Status
01    [db4a22d0] (000/095) No match
02    [53ff39a0] (026/099) Accurately ripped
03    [4269846f] (025/099) Accurately ripped
04    [e78babb6] (024/096) Accurately ripped
05    [63aa7ee4] (026/100) Accurately ripped
06    [d90c3a31] (025/098) Accurately ripped
07    [56ac3dc9] (024/097) Accurately ripped
08    [94e3cb88] (026/096) Accurately ripped
Offsetted by -1187:
01    [ea73d4df] (000/095) No match
02    [e348df57] (012/099) Accurately ripped
03    [a4e0fe5e] (013/099) Accurately ripped
04    [88c4099b] (013/096) Accurately ripped
05    [abb5dca8] (013/100) Accurately ripped
06    [88ac357e] (013/098) Accurately ripped
07    [076dfa13] (013/097) Accurately ripped
08    [97fe8420] (013/096) Accurately ripped

(edited)

Track Peak [ CRC32  ] [W/O NULL]
--  93.8 [8CF6F2CF] [4F9382CA]         
01  87.9 [94FF746C] [38EE23BC]         
02  93.8 [98852A53] [6F75C85C]         
03  91.7 [BAC2FC05] [76E8E3E3]         
04  64.7 [C8DC7D44] [3DCC4E18]         
05  87.6 [067ADAF0] [83DA9F5E]         
06  89.2 [5AD30B16] [B57A34EB]         
07  82.6 [FC1B168A] [D753063A]         
08  87.5 [468FAF05] [3EBF666F]         
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nowings69 on 2011-03-16 05:20:57
Please rip it with latest EAC again
dont forget LOG is in English
and let me see here your LOG
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2011-03-16 11:38:04
The crcs without zero are the same. Probably without the cuesheet the pregap of 33 is within the calculated crc with zeros
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2011-03-16 12:01:17
Please rip it with latest EAC again
dont forget LOG is in English
and let me see here your LOG


it was ripped with XLD, which id hazard a pretty strong guess is central to the problem. unfortunately i no longer have the cd. track 1 looks like this.. the files havent been altered other than for tagging so i would imagine its very likely "AccurateRip signature  : 7FF67560" is correct for this track. im just curious as to why cuetools gives a different value based on whether the cue file is present or not.

    Track gain            : -3.71 dB
    Peak                  : 0.879486
    CRC32 hash (test run)  : 3A958896
    CRC32 hash            : 3A958896
    CRC32 hash (skip zero) : 38EE23BC
    AccurateRip signature  : 7FF67560
        ->Accurately ripped! (confidence 21)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0
        Inconsistency in error sectors      : 0
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-03-16 12:47:21
Note that without CUE sheet AccurateRip ID changes, that means that CUETools wasn't able to determine track lengths correctly.

My guess is that your track 1 also contained HTOA (track 0) prepended to it.

You should trust verification result with CUE Sheet. Without it CUETools is not always able to correctly guess the track lengths. It assumes that rip was done in gaps appended (noncompliant) mode, and yours is slightly different due to the way pregap was handled.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Darfo9 on 2011-03-17 00:20:22
The local db is a very nice feature.
I request that you write to the db after every verification.
It would also be nice if multiple instances could write the db correctly, for one.
More significantly, my first 48 hours of verification were lost due to crash, corrupt db.
Unfortunately I do not have any information on that crash.
Also, as was mentioned previously, writing the application log to disc after each verification would be very helpful.
It would help me find some rips where I saved the wrong cuesheet, for one thing.

I have used ArCueTool with mono for verification for a long while.
No success with the full CUETools after version 1.9.5.
This version was closer to functional with mono... I gave in and tried in a Win7x64 VirtualBox VM.
This could be part of the reason for my second issue (the filesystem is shared from the host in VBox).
Two directories (the largest ones) will not add to local db, or open in multiselect.
Instead, the name changes in the tree, and an error is reported, different for each dir:
'Illegal characters in path..'
'Second path fragment must not be a drive or UNC name.
Parameter name: path2.'
I will try sharing the drive with samba instead. I expect it can avoid presenting characters windows dislikes.

I would be happy to help identify any mono problems also.
Currently there is a crash if settings is opened more than one time.
Also the 'Array Index is out of range." issue others mentioned.
Got external decoders working for the first time though, so it is looking close to usable on linux by now.

Great program. I appreciate it a lot.
If I can scan my archive into local db, that will be very helpful in pruning out some old duplicates, with good knowledge that I am keeping the right version at a glance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-17 08:16:00
Bug (or maybe just a bad behavior):
The new database report as AR(1) rips that are not AR(1) within the same offset for all tracks:

Exemples:
Code: [Select]
[CUETools log; Date: 17/03/2011 01:54:50; Version: 2.1.1]
[CTDB TOCID: b6gm9OlJdrcf4Tg_8v0zf4blTzI-] disk not present in database.
[AccurateRip ID: 0017ec1c-00c283cb-7d0fc30a] found.
Track   [ CRC    ] Status
01     [ee75877b] (0/1) No match
02     [a42162d5] (0/1) No match
03     [2c9b2173] (0/1) No match
04     [9d6dde86] (0/1) No match
05     [01e28cbd] (0/1) No match
06     [086d5cd8] (0/1) No match
07     [beacb897] (0/1) No match
08     [771e0e75] (0/1) No match
09     [88b4d0ec] (0/1) No match
10     [10dbdb63] (0/1) No match
Offsetted by -30:
01     [248faa5b] (1/1) Accurately ripped
02     [e20bdec7] (1/1) Accurately ripped
03     [82a5426f] (1/1) Accurately ripped
04     [8c418997] (1/1) Accurately ripped
05     [a9728e8d] (1/1) Accurately ripped
06     [8846b6ca] (1/1) Accurately ripped
07     [0f09d762] (1/1) Accurately ripped
08     [7669c547] (1/1) Accurately ripped
09     [3298a756] (0/1) No match
10     [7b9740c7] (1/1) Accurately ripped
Offsetted by -24:
01     [66c6e8ea] (0/1) No match
02     [da8ab2d0] (0/1) No match
03     [714c6f08] (0/1) No match
04     [648edaac] (0/1) No match
05     [28ce489a] (0/1) No match
06     [f8ee815b] (0/1) No match
07     [fedcd139] (0/1) No match
08     [a9c1071d] (0/1) No match
09     [43d17c74] (1/1) Accurately ripped
10     [330b5fb3] (0/1) No match

Track Peak [ CRC32  ] [W/O NULL]
--  100,0 [3F152733] [3705D836]          
01  100,0 [D59F28F5] [3133D51F]          
02  100,0 [F2992133] [753725E0]          
03  100,0 [5947389A] [C7567C3A]          
04  100,0 [8769CA2F] [064C83B1]          
05  100,0 [FBEC632D] [32BE3824]          
06  100,0 [7A956A4D] [94BE15FB]          
07  100,0 [5326ACC9] [2D0DECF0]          
08  100,0 [A7D889D3] [FF0A9321]          
09  100,0 [F414995E] [7809B389]          
10   95,0 [F21F2CFC] [4E510C8B]


Code: [Select]
[CUETools log; Date: 17/03/2011 02:51:31; Version: 2.1.1]
[CTDB TOCID: h7JhPbXF2hMv1zdpHSVjhU2.AoI-] disk not present in database.
[AccurateRip ID: 0002e749-000bf24c-1e045e04] found.
Track   [ CRC    ] Status
01     [76d91483] (0/2) No match
02     [dc6a953e] (1/1) Accurately ripped
03     [172d3cec] (1/1) Accurately ripped
04     [596ac875] (1/1) Accurately ripped
Offsetted by -2031:
01     [492fd62c] (2/2) Accurately ripped
02     [35a43578] (0/1) No match
03     [f7aef392] (0/1) No match
04     [89de802f] (0/1) No match

Track Peak [ CRC32  ] [W/O NULL]
--   95,4 [490CDC9E] [E90C5853]          
01   75,7 [CB9EA3B1] [650B95EC]          
02   95,4 [3F5C2ADD] [0FF12F32]          
03   73,4 [36161983] [F4EC209D]          
04   75,8 [C53DE965] [6832AA53]


Shouldn't those be just not accurate? (Well not yet, even if a match is a match) cauz if the database behavior is the normal one, then the problem is with the batchlog which report those as "rip not accurate (1/1)", there is a consistency problem somewhere. Either it's AR(1) or it's not AR(1), it cannot be both at same time (even at two different place within CT).

By the way, if there is not a quick fix soon for the HDCD non-detection bug, personnaly I think I will go back to V2.0.9. I think the new database is nice but not polished & in the same time the HDCD non-detection annoys me. Actually I still prefer copy/pasting the batchlog & do manual sorting (using a TXT search engine) as AR(1) report is partially erroneous & the database miss "not present in database" results anyway. So V2.1.1 brings me no-gain for a loss.

Gregory S. Chudov:
Quote
Waiting with anticipation for your complaints wink.gif

I hope I complained enough for your taste  I am done for V2.1.1 !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-03-17 17:36:49
Either it's AR(1) or it's not AR(1), it cannot be both at same time (even at two different place within CT).

None of the logs you posted show both at the same time.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-17 22:13:00
Sorry if it wasn't clear, the problem is not within the logs, it's the database vs. the batchlog, the database sort those results within the "accuraterip confidence 1" folder while the batchlog report those as "not accurate". So for the database it's AR(1) & for the batchlog it's AR(0) [if you consider that an overall AR(1) result where all AR(1) results are spreaded among several offsets/pressings is in fact not accurate, no matter if a match is a match which was the default behavior so far]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-17 23:01:30
I just noticed that the "problem" seems generalized as it also affects rips with a higher accuraccy than just AR(1):

The two following logs are sorted in accurate folders (with mid/high level) in the database while reported as not accurate in the batchlog.

Note: Those two rips are really strange anyway as the pressings only differs by offset+1 & at the same time the accuracy level is nearly the same among the two "different" pressings. So it looks as if it was the same pressing splitted by a +1 offset. Any idea why this happens ?

Code: [Select]
[CUETools log; Date: 17/03/2011 13:54:05; Version: 2.1.1]
[AccurateRip ID: 000c10fa-00564dc5-59075109] found.
Track   [ CRC    ] Status
01     [27f8cb35] (00/15) No match
02     [33349032] (00/15) No match
03     [db805bf9] (00/15) No match
04     [b564b571] (00/15) No match
05     [54494d7c] (00/15) No match
06     [7bc575f5] (00/15) No match
07     [a030f16b] (00/15) No match
08     [0b7d1c2b] (00/15) No match
09     [15324d80] (00/15) No match
Offsetted by 1360:
01     [77b82b05] (00/15) No match
02     [991c04b2] (00/15) No match
03     [55238589] (00/15) No match
04     [c3298571] (15/15) Accurately ripped
05     [ff0e9f5c] (15/15) Accurately ripped
06     [2de9acd5] (15/15) Accurately ripped
07     [474ccacb] (15/15) Accurately ripped
08     [e8322ff7] (15/15) Accurately ripped
09     [1752a2b1] (15/15) Accurately ripped
Offsetted by 1361:
01     [cbeb520e] (15/15) Accurately ripped
02     [bcc2c6da] (15/15) Accurately ripped
03     [3cf222be] (15/15) Accurately ripped
04     [c4ad9e71] (00/15) No match
05     [60b04602] (00/15) No match
06     [a16e988b] (00/15) No match
07     [27fcd009] (00/15) No match
08     [98b50f8a] (00/15) No match
09     [0f7d89db] (00/15) No match

Track Peak [ CRC32  ] [W/O NULL]
--   99,9 [3E2034F7] [454DA1E4]          
01   74,5 [CC146E29] [C3A675C9]          
02   73,9 [C0263C1A] [FD4311C2]          
03   82,7 [FD7A83F8] [84020FA1]          
04   81,1 [2F855D52] [33DDBA90]          
05   87,5 [B1ECE243] [CAE1DCB2]          
06   89,3 [39B10FE7] [6FE6A47E]          
07   99,9 [3800A228] [475E2E8F]          
08   99,8 [E5FCC4DB] [474DA738]          
09   95,9 [B5AD0324] [16862305]
     


Code: [Select]
[CUETools log; Date: 17/03/2011 13:50:08; Version: 2.1.1]
[AccurateRip ID: 0017b795-00cc6faa-850d110b] found.
Track   [ CRC    ] Status
01     [fdb6fd32] (00/72) No match
02     [ef20570e] (00/73) No match
03     [6adb4a5e] (00/72) No match
04     [64fb2a8c] (00/71) No match
05     [3c3f5b2f] (00/70) No match
06     [c5cfb392] (00/71) No match
07     [57bec47a] (00/71) No match
08     [e11727d9] (00/71) No match
09     [cf4c17dc] (00/72) No match
10     [e23a5f7e] (00/71) No match
11     [6a143907] (00/66) No match
Offsetted by 5:
01     [4509d1f6] (00/72) No match
02     [c02e4492] (13/73) Accurately ripped
03     [924f2fa3] (00/72) No match
04     [46b863b0] (00/71) No match
05     [00221419] (00/70) No match
06     [fda88900] (00/71) No match
07     [648501ab] (00/71) No match
08     [601f5741] (00/71) No match
09     [c4776133] (00/72) No match
10     [d491ef21] (00/71) No match
11     [4527317d] (00/66) No match
Offsetted by 6:
01     [201a62ea] (13/72) Accurately ripped
02     [b6caa746] (00/73) No match
03     [44783bde] (13/72) Accurately ripped
04     [40ab08b6] (13/71) Accurately ripped
05     [5a829f7b] (13/70) Accurately ripped
06     [3c071a16] (12/71) Accurately ripped
07     [67130de8] (12/71) Accurately ripped
08     [46542d89] (12/71) Accurately ripped
09     [5be66fde] (12/72) Accurately ripped
10     [0509d8a8] (12/71) Accurately ripped
11     [a9c82d5a] (11/66) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   99,9 [527629B7] [E560279D]          
01   87,0 [426441B0] [C18F2AC9]          
02   86,8 [0ADC0ABA] [A7A7A3FE]          
03   99,9 [9BAF25F8] [16C545C9]          
04   86,8 [B6F1956D] [7027D37B]          
05   99,9 [0178F0E4] [78B8C4D2]          
06   99,9 [34C23BFC] [6FD77973]          
07   99,9 [EFC4282B] [976B1599]          
08   86,6 [9833FDBC] [42AF91F7]          
09   87,2 [314FA6FC] [5801148C]          
10   87,7 [C06D17DF] [4B9E5298]          
11   86,5 [826C7ACB] [8B089D49]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: liquefied on 2011-03-17 23:32:26
I love this program but found some sticky things.

Look at the logs below (I've edited to only the problem area). 2.1.1 log shows no match yet in the bottom right corner while processing it, it clearly said "AccurateRip: found" (2). So does that mean that 2.0.9 was correct, but if so, why does it say no match too, but 2/2? Or is 2.1.1 correct in this case?

Code: [Select]
[CUETools log; Date: 3/17/2011 6:46:05 PM; Version: 2.1.1]
Offsetted by -646:
01     [cc71dedb] (0/2) No match but offset
02     [25fdfe05] (0/2) No match but offset
03     [81a2ed11] (0/2) No match but offset
04     [cd0713ed] (0/2) No match but offset
05     [a010b224] (0/2) No match but offset
06     [f0393be7] (0/2) No match but offset
07     [d1401d51] (0/2) No match but offset
08     [89d05b18] (0/2) No match but offset
09     [2fc9c665] (0/2) No match but offset
10     [ce850037] (0/2) No match but offset
11     [5063e83e] (0/2) No match but offset


Code: [Select]
[CUETools log; Date: 3/17/2011 6:49:01 PM; Version: 2.0.9]
Offsetted by -646:
01     [cc71dedb] (2/2) No match but offset
02     [25fdfe05] (2/2) No match but offset
03     [81a2ed11] (2/2) No match but offset
04     [cd0713ed] (2/2) No match but offset
05     [a010b224] (2/2) No match but offset
06     [f0393be7] (2/2) No match but offset
07     [d1401d51] (2/2) No match but offset
08     [89d05b18] (2/2) No match but offset
09     [2fc9c665] (2/2) No match but offset
10     [ce850037] (2/2) No match but offset
11     [5063e83e] (2/2) No match but offset


Also "Write AccurateRip log" > "In source folder" does not work at all. I have tried it many times. It only writes into the the target output folder. So maybe that should be have a tooltip over it that it really doesn't work currently.

Suggestion for the website: it still shows screenshots of version 2.0.3 and I see artifacts on them too too. So replace them with PNG screenshots of 2.1.1?

Is there an official help file for CueTools? I would love to write one, but I probably wouldn't be really useful for that. It might be useful though. That way you know what the custom scripts under the main "Action" box do (Encode/Verify/etc). I love how Sonar X1's has a help button on each page of options and when you click it, it's about the page you were on. Useful!

The template box is totally frozen and greyed out if you switch to Verify under actions when using the Default profile. However if you go to Encode first, change it there, then go back, that new template will be used, but its' greyed out again under verify. But if you choose the verify PROFILE then you can change it while under Verify. Another minor bug.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-17 23:58:39
liquefied:
In your case there is a result in the database with a confidence 2, but you just don't match maybe because you have another pressing. Providing you corrected offset while ripping, you shoudn't correct offset when you don't match (I see it's Offsetted by -646), because then you obviously try to match a pressing that is not yours. Just wait for your pressing to appear. As for (0/2) vs. (2/2), I think (0/2) is a better way of displaying as it doesn't match, but what matters anyway is the "No match but offset" line.

Quote
Also "Write AccurateRip log" > "In source folder" does not work at all.

It works for me, maybe this is related to the way you outputs results (I dunno)
I use [%directoryname%\]%filename%-new[%unique%].cue & with the right ticked options, it does create an CDImage-new.accurip in each folder.

Be sure "Write AccurateRip log" is ticked for both "verify" & "encode & verify", not just "verify" if you encode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-18 08:21:55
Suggestion:
Could the "drag & drop mode" be always be visible on the left & on top of the "local database". (unless you "hide browser" indeed)

The "drag & drop mode" only take 1 line so it is boring to always have to switch between "drag & drop mode" & "local database" when both could be displayed at the same time.

IMHO, there should only be 4 inputs display:
-Folder browser
-Multiselect browser
-Drag & drop+Local database
-Hide browser
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2011-03-18 11:44:34
... Also "Write AccurateRip log" > "In source folder" does not work at all. I have tried it many times. It only writes into the the target output folder. So maybe that should be have a tooltip over it that it really doesn't work currently. ...

It works for me too.

It is an option only for verifying. When it is not enabled the destination folder will be created according to the templete.

If you also convert the log will always be saved in the output folder. ("Encode and verify > Write Accurate Rip log" does not have this option.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: 420 MuNkEy on 2011-03-18 11:58:37
FLACCL is unable to write mono files.

stereo test:
Code: [Select]
CUETools_2.1.1>CUETools.FLACCL.cmd.exe -8 -o test-stereo.flac test-stereo.wav
FLACCL#0.4, Copyright (C) 2010 Gregory S. Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : test-stereo.wav
File Info : 44100kHz; 2 channel; 16 bit; 00:03:58.0270000
Results   : 192.11x; 30975986 bytes in 00:00:01.2390000 seconds;


mono test:
Code: [Select]
CUETools_2.1.1>CUETools.FLACCL.cmd.exe -8 -o test-mono.flac test-mono.wav
FLACCL#0.4, Copyright (C) 2010 Gregory S. Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : test-mono.wav
File Info : 44100kHz; 1 channel; 16 bit; 00:03:58.0270000
Error     : EnqueueWriteBuffer failed with error code INVALID_VALUE

I tried with other mono wavs with the same results.
I know mono is kind of rare on CDs, but I'd really love to see support added if it's not much trouble
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2011-03-19 17:35:17
Suggestion:
Could the "drag & drop mode" be always be visible on the left & on top of the "local database". (unless you "hide browser" indeed)

The "drag & drop mode" only take 1 line so it is boring to always have to switch between "drag & drop mode" & "local database" when both could be displayed at the same time.

IMHO, there should only be 4 inputs display:
-Folder browser
-Multiselect browser
-Drag & drop+Local database
-Hide browser


I think this is an excellent idea. It is a bit of extra clicking that gets tiresome after a bit... clicking to change over to see the local database view. While I haven't had a chance to read the documentation to see exactly how the local database works (other than obviously a database/logging of what you've scanned and the results)... I don't know if it's used as a cache or anything, but regardless... I think it's a smart idea, since I like to take a look at the local DB often... and i agree with sauvage, in drag and drop mode, could we show the local database in a side pane (or have the option too) in drag and drop mode have your left pane, and have a horizontal splitter, top (or bottom) would show the local database, while the other portion would act as a "drop pad" for the files to be dropped on, as he does have a good point in that the drop area doesn't have to be that big. So i just wanted to +1 to his suggestion.



While we're at it, I have one very small suggestion -- can the queue log/output window do a simple word wrap? I don't know what it's written in, but in most of the Visual languages it's a simple property you set for that text box, for word wrap (like I'm telling you something new, haha). that would allow one to see the entire output of the process without having to have the unsightly horizontal scrollbar or having the window wide as the whole screen. it'd be a great space saver for those wanting to resize the window smaller. or, as said, if not the default, at least could it be an option? maybe double click the text area to toggle it on or off or a little icon next to the progress bar/status icons? Right now, I'm using a 1080p monitor, so with 1920 horizontal pixels, for me to get the horizontal scrollbar to disappear and for me to see the full output line at once, i have to resize the window to approximately 60% of my screen's width. It's not a huge deal, but it does make it more cumbersome when I have an explorer window up for my files, and then maybe another accurip log up for comparison, etc.... I have to constantly keep minimizing CueTools out of the way to see everything. [EDIT: I just realized that this only is a problem in non-verbose mode, where the single output line is very long, the problem is solved it seems to me, by cutting on verbose logging, which gives it the look that is seen in my beautiful design artwork. "Paint" doesn't intimidate this guy....]

I don't want to leave with a bad impression, so I want to say that I am very pleased to see a new version after all this time, from what I really began to think was an abandoned project and I felt that CueTools was dead in the water. I hope to see more versions and further ideas and progress in the future! You're doing a great job! Hopefully we can see more frequent updates, even if they only introduce a few small features or fixes at a time... you had me worried!

Imagine... you have the "hide browser" option on... the side is hidden. Now your window is quite small, though with a lot of scrolling to do for the output. If we had it wrap, we could see
the whole output, without scrolling sideways, even in this collapsed view. Now, looking at this view on my computer, we have two perfectly good, but unused spaces. the area directly below the "Action" area and to the left of the "Extra" area. Perfect drop pad for drag and drop mode! The other is directly below the three checkbox options for CTDB, LDB, and skip recent. That's another pefectly good size of a blank area to drop files into. Possibly just put a little icon indicator there, or text to show "hey this is your drop area for files" -- I think that's an amazing idea, if I even say so, myself, haha...

In Windows 7, they could use this view and use the whatever it is... Snap feature or whatever, so it docks to 25% of the screen or whatever it is... and how I can see a long vertical listing, if i'm doing recursive or a lot of queued work.

If it lets me attach my image correctly (maybe you have to open the attached jpg), reference that for a visual mock-up. Note that I made things as small as I could, but the two windows are both docked to the side of the screen, and this display that you see only takes up 50% of my screen's width. I could have up to 4 windows tiled vertically and talk about doing some multitasking.... The dealbreaking problem of this was that I had to undock the window, and hit "Drag and drop mode", which popped out an entire, unnecessary left column... then I dragged my file onto it, then hid it again, and redocked. What a pain. That could be eliminated by using the design I show here:

[attachment=6405:cuetools_mockup.JPG]


If anyone agrees or disagrees with this suggestion, please post about it, so we can see if other people would be interested in the same idea. So maybe have 5 options... the 4 sauvage offered, and a fifth -- collapsed view or minimal DND view.

Thanks for considering/reading my ideas... and if you're impressed by my art -- I'm available for hire. Just let me know...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2011-03-19 18:38:53
Still hoping cuetools will be able to read TOC from vorbis/flac tags.

http://forum.dbpoweramp.com/showthread.php?t=16705 (http://forum.dbpoweramp.com/showthread.php?t=16705)

I have thousands of albums I would like to scan and update the CTDB with and they all have the TOC in the meta-data as above and many are not added because cuetools cannot currently read these tags.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xz_kostyan on 2011-03-19 22:24:02
Hello.

I found than 'Array index is out of range..' error (which occurs with mono) doesn't occur when checkbox 'use Accurate Rip' is unchecked. (http://gyazo.com/f5d80b0ebd53f388a988cdb0dac6eaf5.png)

So, it seems that there is problem in the AccurateRip summer module. Also, I've checked previous versions of CUETools, and found that this error doesn't appear in 2.0.3_x86 and 2.0.4a_x86. I've tried to replace 'CUETools.AccurateRip.dll' from these versions to newest 2.1.1, but get exception at program start.

This problem reproduced under ubuntu with mono JIT compiler version 2.6.7.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-20 16:12:15
Not a bug but an annoying behavior, when you use the browser to add a folder & search for dupes & click on "not yet verified clones", the results are sorted from Z to A in the batchlog instead of from A to Z (Note: at the same time it is sorted from A to Z in the local database), it is annoying as it forces you to browse the batchlog from the bottom to the top instead of from the top to the bottom. Nothing terrible, but still it's annoying.

Sorry if my list of requests never ends ... this just reflects how usefull CT is for me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zsero on 2011-03-21 04:13:26
24-bit HDCD decoding is broken in 2.1.1. I had to go back to 2.0.9 (which link was a guess, but it worked).

BTW, is there any possible script which would go through a whole media library and decode all the CDs which it detecs as HDCD? But only the HDCD ones.

Or is it not needed now, that foobar2000 has a HDCD component? Is the foobar2000 component on a level as the one in CUETools?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2011-03-21 19:28:27
Tried the new 2.1.1 version. Always glad to see new developments.
I used it a evening, but went back to 2.0.9 when I came across this behaviour: After a lookup it won't lookup the same cd-directory again, it gives a message of: recently verified.
If a user says verify, it should verify. I often change a pregap setting to find a better match but I had to change directory name to verify again, that became an annoyance very soon.
Couldn't find a setting to disable it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SlowPulse on 2011-03-21 19:31:54
Tried the new 2.1.1 version. Always glad to see new developments.
I used it a evening, but went back to 2.0.9 when I came across this behaviour: After a lookup it won't lookup the same cd-directory again, it gives a message of: recently verified.
If a user says verify, it should verify. I often change a pregap setting to find a better match but I had to change directory name to verify again, that became very soon an annoyance.


There's a checkbox saying "Skip recently verified" which can be turned off.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-03-21 21:25:19
There's a checkbox saying "Skip recently verified" which can be turned off.


Not on mine. There's a picture of a clock with a checkbox. There's no text (not even when I hover) but that is the checkbox SlowPulse is referring to. Changing SkipRecent=1 to SkipRecent=0 in settings.txt unticks that box and allows me to verify with a different pregap.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a3aan on 2011-03-21 22:20:25
Decoding is the same in the Foobar plugin AFAIK. However, the Foobar plugin is more advanced. One can suppress the -6db when peak extension is not enabled.

..
BTW, is there any possible script which would go through a whole media library and decode all the CDs which it detecs as HDCD? But only the HDCD ones.

Or is it not needed now, that foobar2000 has a HDCD component? Is the foobar2000 component on a level as the one in CUETools?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: liquefied on 2011-03-22 01:48:05
Well I had it enabled like everybody said, and I only verify anyways, in source folder is just broken for me. It has never once ever worked. It will only work when I use the template that basically points to the source folder (which defeats the setting in options), it always only puts the the results in the new destination output.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SlowPulse on 2011-03-22 08:48:47
There's a checkbox saying "Skip recently verified" which can be turned off.


Not on mine. There's a picture of a clock with a checkbox. There's no text (not even when I hover) but that is the checkbox SlowPulse is referring to. Changing SkipRecent=1 to SkipRecent=0 in settings.txt unticks that box and allows me to verify with a different pregap.


Curious. I can enable/disable it in the GUI, and it works as one would expect... "Skip recently verified" appears when I hover the icon.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-03-22 11:15:16
"Skip recently verified" doesn't appears when I hover the icon too, I didn't even knew what this new icon was doing untill someone posted the answer here. But in my case I think it is related to the fact that I use 125% fonts which creates various displaying glitches with CT. It's likely that if I switch back to 100% fonts, it will appear when I will hover the icon (I haven't tested as I would need to reboot).

EDIT1:
I just rebooted & tested, the tip still doesn't appear when I hover the icon at fonts 100% so it's unrelated for this bug. But I also tested the display bug reported in Post #1258 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=1250&p=747398&#entry747398) & this one is related to the font size, it disapear if I switch back to font 100%.

EDIT2: Bad Link.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-03-22 12:59:03
There's a checkbox saying "Skip recently verified" which can be turned off.


Not on mine. There's a picture of a clock with a checkbox. There's no text (not even when I hover) but that is the checkbox SlowPulse is referring to. Changing SkipRecent=1 to SkipRecent=0 in settings.txt unticks that box and allows me to verify with a different pregap.


Curious. I can enable/disable it in the GUI, and it works as one would expect... "Skip recently verified" appears when I hover the icon.


I can enable/disable it in the GUI, just didn't know what the clock icon was without the 'hover' text. Your original post mentioned the text but didn't mention where to find it or that it was associated with an icon. I just used the changes in settings.txt to verify that the clock icon was indeed for the SkipRecent setting.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SlowPulse on 2011-03-23 22:32:33
is there a way to remove something from database? i have a bunch old rips done with EAC 0.95 wich don't have data track length info anywhere.
i've entered the length manually and did verification, but this doesn't update the old entry, it creates new one, and now i have uneeded old verifications without data track length
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-03-31 16:03:36
Comodo Antivirus is now reporting CUETools.FLACCL.cmd.exe as UnclassifiedMalware@181942124
According to VirusTotal it is the only antivirus program that has a problem with the file so far. I assume it is a false report.
I've been using 2.1.1 for several weeks and this is new this week.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nino-kun on 2011-04-08 17:59:59
I have a little request.

Is it possible to make support for OGG Flac format? It's not very popular, but other program what i use  support it, and only CUETools not.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 2011-04-08 18:29:32
Comodo Antivirus is now reporting CUETools.FLACCL.cmd.exe as UnclassifiedMalware@181942124
According to VirusTotal it is the only antivirus program that has a problem with the file so far. I assume it is a false report.
I've been using 2.1.1 for several weeks and this is new this week.

Please report the false positive to Comodo: http://www.comodo.com/home/internet-security/submit.php (http://www.comodo.com/home/internet-security/submit.php)
(You should first check that your "CUETools.FLACCL.cmd.exe" file has not changed. For instance, extract a new copy of the file from the original package and test it with Comodo.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-04-08 22:09:01
Comodo Antivirus is now reporting CUETools.FLACCL.cmd.exe as UnclassifiedMalware@181942124
According to VirusTotal it is the only antivirus program that has a problem with the file so far. I assume it is a false report.
I've been using 2.1.1 for several weeks and this is new this week.

Please report the false positive to Comodo: http://www.comodo.com/home/internet-security/submit.php (http://www.comodo.com/home/internet-security/submit.php)
(You should first check that your "CUETools.FLACCL.cmd.exe" file has not changed. For instance, extract a new copy of the file from the original package and test it with Comodo.)


Already reported.
Scanned freshly downloaded untouched rar with comodo and still shows CUETools.FLACCL.cmd.exe as malware.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-04-13 14:11:41
I've searched this topic but nothing found: is it planned to verify XLD extraction logfiles along with EAC logs?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: djray on 2011-04-16 19:54:32
Great, great app!  Wanted to convert a FLAC album with pregap information in the CUE sheet to lossy MP3 on my portable player and now my album plays without gaps!

Is it possible to write settings to the folder where CUETools.exe is located, instead of the /%APPDATA%/CUE Tools/ folder?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2011-04-16 20:51:05
Is it possible to make support for OGG Flac format? It's not very popular, but other program what i use  support it, and only CUETools not.

CUE Tools already supports FLAC. In fact it's the first on the list of the lossless codecs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nino-kun on 2011-04-24 05:58:41
CUE Tools already supports FLAC. In fact it's the first on the list of the lossless codecs.

Yes, it's support FLAC, but OGG Flac (FLAC in OGG container) is not supported. Or, maybe, i don't understand how make it work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2011-04-25 09:45:24
Quote
Curious. I can enable/disable it in the GUI, and it works as one would expect... "Skip recently verified" appears when I hover the icon.

Thanks I found it, was looking for it in the settings.

Another 'problem' arose:
I have a rip which isn't accurate:
Code: [Select]
[CUETools log; Date: 25-4-2011 8:36:00; Version: 2.1.1]
[CTDB TOCID: uQhRJNYJ1Vsn06JKtFWe8CcCIe4-] found.
        [ CTDBID ] Status
        [a06cc7cf] (406/929) Differs in 28 samples @20:43:55-20:43:56,20:43:68
        [a06cc7cf] (406/929) Differs in 28 samples @20:43:55-20:43:56,20:43:68
        [c3cec891] (076/929) No match
        [f4a547fa] (041/929) CD-Extra data track length 25:23:73, No match
[AccurateRip ID: 0013772e-00b8c3d1-920aca0c] found.
Track   [ CRC    ] Status
01     [951d91ae] (173/610) Accurately ripped
02     [f56c3d1a] (177/619) Accurately ripped
03     [69b12260] (174/618) Accurately ripped
04     [87ddc1cd] (173/615) Accurately ripped
05     [d2da3a5d] (172/612) Accurately ripped
06     [30295ad7] (000/609) No match but offset
07     [f28fed89] (169/612) Accurately ripped
08     [a436080c] (173/614) Accurately ripped
09     [a3c36af0] (167/607) Accurately ripped
10     [5005d51b] (172/610) Accurately ripped
11     [5765bc33] (169/606) Accurately ripped
12     [9a4d451e] (163/593) Accurately ripped
Offsetted by -664:
01     [9202d25a] (009/610) Accurately ripped
02     [b5855a46] (009/619) Accurately ripped
03     [a52eaf80] (009/618) Accurately ripped
04     [17ce7ebd] (009/615) Accurately ripped
05     [913d8c8d] (009/612) Accurately ripped
06     [89172697] (000/609) No match but offset
07     [84a4f315] (009/612) Accurately ripped
08     [8bed92b8] (009/614) Accurately ripped
09     [df1e3be4] (009/607) Accurately ripped
10     [ad994c1b] (009/610) Accurately ripped
11     [a4938597] (009/606) Accurately ripped
12     [0d4b915a] (009/593) Accurately ripped
Offsetted by -120:
<snip>
Track Peak [ CRC32  ] [W/O NULL]
--   98,8 [FABFD1FE] [E3683F85]          
01   98,8 [A9078FAD] [FC24B957]          
02   98,8 [08F01D02] [242D4BC6]          
03   98,8 [2C8F9748] [41D1E97F]          
04   98,8 [CB5000BC] [AA220732]          
05   98,8 [03169DF2] [39924238]          
06   96,7 [E43D75CE] [C218F1F2]          
07   97,4 [6BD5B831] [CED9E331]          
08   98,3 [9FA04F45] [EA691BAC]          
09   98,8 [50672502] [F024CB76]          
10   98,5 [078F1A9C] [3129B119]          
11   98,8 [0B13B96C] [498F859D]          
12   98,8 [818CEBE9] [E7BBCDE7]


Problem: I can't repair it, there 's no possibility (afaict) to tell cuetools which CTDBID to use  if there's more than 1.
Cuetools just verifies.
maybe small bug: also one CTDBID is mentioned twice
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dirki on 2011-04-25 13:48:41
How can I make profiles with Cue-Tools?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dirki on 2011-04-25 13:52:01
Is it possible to make Cue-Tools faster? It takes about 12 minutes on my system to convert a flac album to mp3.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-04-25 15:09:55
Is it possible to make Cue-Tools faster? It takes about 12 minutes on my system to convert a flac album to mp3.

The flac decoder is actually quite fast. Such low speed can probably be only explained by slow LAME mp3 encoder.
Do you use the lame.exe or lame_enc.dll version? Where did you download it?
You can download good optimized lame encoders from rarewares dot org.
Also if you use lame.exe you might want to check command line in advanced options in CUETools
(Encoders->"lame cbr" for example uses -q 0, i.e. highest quality and slow compression).
Quality settings for lame_enc.dll cannot be selected in current CUETools version,
and highest quality is used by default. I will probably add this option in the next version.

But another possible reason for such slow encoding might be that you are encoding
directly to USB-connected mp3 player. I had the same problem with my COWON S9 -
it doesn't handle small writes very well, so i ended up encoding to a HDD path,
and then copying the result to the player manually. I'm still working on a solution
for this problem, i'll probably have to detect if the target drive is removable
and use some kind of buffering in this case.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-04-25 15:16:36
How can I make profiles with Cue-Tools?

Click the "default" button with a basket, then the first (empty) menu item and enter the name of the new profile. Don't use characters that cannot be used in a file name. Then press return.

I was told current profiles system is quite inconvenient, but i didn't find time to enhance it yet.
I personally only use "default" profile and the one i created once for my portable player, and it kinda works if you're careful
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-04-25 15:32:26
I found than 'Array index is out of range..' error (which occurs with mono) doesn't occur when checkbox 'use Accurate Rip' is unchecked.

Oops, forgot to test this version with mono. Does this happen on every CD or only on a particular one?

24-bit HDCD decoding is broken in 2.1.1. I had to go back to 2.0.9 (which link was a guess, but it worked).
BTW, is there any possible script which would go through a whole media library and decode all the CDs which it detecs as HDCD? But only the HDCD ones.
Or is it not needed now, that foobar2000 has a HDCD component? Is the foobar2000 component on a level as the one in CUETools?

Yep, it's broken  Will be fixed in the next version. Such script is probably possible, but i didn't try to write one yet. foobar2000 component probably uses the same HDCD library by Christoper Key, so there shouldn't be a problem there.

Already reported.

Thanks.

I've searched this topic but nothing found: is it planned to verify XLD extraction logfiles along with EAC logs?

I guess so  But i'm a bit overstretched at the moment. I'm trying to do too many things at once. So for now i decided to focus on CTDB and AR2 and Local DB. Would be really cool if there were some developers ready to help with at least the more trivial stuff like XLD log parsing. Such things don't require much work each on their own, but there's million of them.

Is it possible to write settings to the folder where CUETools.exe is located, instead of the /%APPDATA%/CUE Tools/ folder?

Yep, just remove the file called user_profiles_enabled from the CUETools folder.

Yes, it's support FLAC, but OGG Flac (FLAC in OGG container) is not supported.

Yep, it was even supported at some point, but i decided to remove it, because it added about 200-300k to the download size, and you are probably the first user who asked about it. I can probably add some support for it via external decoder, e.g. flac.exe.

Problem: I can't repair it, there 's no possibility (afaict) to tell cuetools which CTDBID to use  if there's more than 1.

I thought CUETools was displaying a choice in such cases. I'll check if it's broken when i get home.
UPD: works for me: (http://img863.imageshack.us/img863/4135/screen3t.th.jpg) (http://img863.imageshack.us/i/screen3t.jpg/)
Make sure you selected 'Encode' action and 'repair' script. Just in case, i removed the duplicate entry from the database. There was a bug for some time last year which caused some duplicate entries, i thought them harmless and didn't get around to remove them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-04-26 20:52:52
One more question.
It was possible to select the appropriate log file if there were several ones in a folder (for example in russian and in english). I don't see this selection window anymore.
Has the last version lost this feature?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Arbie on 2011-04-27 18:19:00
Thanks very, very much for CUETools.  It has completely replaced Foobar2000 for me, because my primary usage is unpacking full-CD APEs and FLACs into their original tracks.  CUETools is much more robust for this.

==>  Which leads to my request:  Please flag fatal errors in color or some other highlight.

I sometimes unpack many CDs at once, and the total pathnames can be long (separate subject...).  The result is that the log window may have hundreds of entries and many of these scroll off to the right.  While it's good to be told that a disc wasn't in the Accurip database, or didn't match what's there, I consider these merely warnings.

But if a track didn't unpack for any reason (often path too long) I REALLY want to know about it!!  And looking for errors like this in the log window is very tedious, because they don't stand out.

I hope you can add some kind of highlighting for these cases.

Thanks again,

Arbie
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2011-04-28 19:28:01
Quote
UPD: works for me:


Because there's only one entry now, I could repair the album now, thanks.
UPD didn't work for me when I first tried to repair this album, but will report back if I find another rip which needs repairing and has more than one CTDB entries. 


I do have a request, I would like the possibility to move the result of a verify to the front of the line, this because the length of path & name of an album is always different and that makes it hard to find the inaccurate ones with batch verifying.
So instead of this:
F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light\01 - Born Under Punches (The Heat Goes On).flac: AR: rip not accurate (0/1), CTDB: could not be verified.
F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light (2006 Expanded Edition)\01 - Born Under Punches (The Heat Goes On).flac: AR: rip accurate (163/179), CTDB: verified OK, confidence 119.
F:\327 - Queen - 1989 - The Miracle\1989 - The Miracle\01 - Party.flac: AR: rip accurate (1/1), CTDB: disk not present in database.
F:\328 - Men At Work - 1997 - Definitive Collection\1997 - Definitive Collection (2003 Remaster) {Anthology}\01 - Down Under.flac: AR: disk not present in database, CTDB: disk not present in database.
F:\329 - Tracy Chapman - 1988 - Tracy Chapman\1988 - Tracy Chapman\01 - Talkin' Bout A Revolution.flac: AR: rip accurate (600/650), CTDB: disk not present in database.

I would like this:
AR: rip not accurate (0/1), CTDB: could not be verified. F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light\01 - Born Under Punches (The Heat Goes On).flac
AR: rip accurate (163/179), CTDB: verified OK, confidence 119. F:\325 - Talking Heads - 1980 - Remain In Light\1980 - Remain In Light (2006 Expanded Edition)\01 - Born Under Punches (The Heat Goes On).flac
AR: rip accurate (1/1), CTDB: disk not present in database. F:\327 - Queen - 1989 - The Miracle\1989 - The Miracle\01 - Party.flac
AR: disk not present in database, CTDB: disk not present in database. F:\328 - Men At Work - 1997 - Definitive Collection\1997 - Definitive Collection (2003 Remaster) {Anthology}\01 - Down Under.flac
AR: rip accurate (600/650), CTDB: disk not present in database. F:\329 - Tracy Chapman - 1988 - Tracy Chapman\1988 - Tracy Chapman\01 - Talkin' Bout A Revolution.flac
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2011-05-10 11:34:48
I have a question regarding local database. Is there a way to remove old entries - for example I moved some albums to different folders and after rechecking cuetools shows them as multiple clones, but I MOVED them, not copied.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-10 11:44:06
There will be. In current version you can only delete the whole database ("C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z")
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2011-05-10 11:50:08
There will be. In current version you can only delete the whole database ("C:\Users\<username>\AppData\Roaming\CUE Tools\LocalDB.xml.z")


Glad to hear that you´re planning this option, beacause rebuilding my database from scratch would be a three days worth of work at least.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2011-05-16 09:02:45
I´m increasingly fond of this local database idea,  its´very useful for me. It would be nice to have more features - like search option, sorting by CTDB confidence etc. Can we have a glimpse at what is the author working on? And what is the release schedule?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-16 10:19:12
Here are some of the major features planned for next release:
1) Updates to CTDB protocol that become necessary due to the database growth, especially because CTDB will hopefully soon be more widely supported
2) Support of musicbrainz NGS metadata via CTDB, providing a fast and convenient access to it.
3) Considerable CTDB verification speed improvement
4) AR v2 support, although in my opinion AR v2 was a huge mistake - this new 'CRC' is not better in any way than the previous one, and it doesn't support offset detection the way the old one did.

I will also try to improve local DB functionality if i have time before the planned release at the end of the month.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-05-16 12:47:08
>4) AR v2 support, although in my opinion AR v2 was a huge mistake - this new 'CRC' is not better in any way than the previous one,
>and it doesn't support offset detection the way the old one did.

AR v2 was AR v1 with the calculation hole fixed, nothing more, nothing less - the offset detection is the same for both.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-16 13:46:25
AR v2 was AR v1 with the calculation hole fixed, nothing more, nothing less - the offset detection is the same for both.

As i have tried to explain to you earlier, it doesn't fix any holes and it destroys the method of offset detection used by CUETools.

Yes, AR v1 was bad, it could even fail to detect a single-bit error, when a good 32-bit crc should be able to reliably detect a 32-bit burst error. Even basic XOR operation does that.

But who says AR v2 is immune to even single-bit errors? I'm pretty sure it's not. It's just a bit more obscure exactly which bits it fails to detect, because it now depends on the audio data, where in previous version those positions were fixed.

And when verifying with AR v2 you can only use CRCs from the same pressing as yours. Verifying against CRCs from several pressings would require the application to detect those pressing offsets in advance using magic 450th frame CRCs, and then calculate CRCs for all of those offsets independently, decreasing verification speed by an order of magnitude. I will not implement that in CUETools, it's just too slow.

First of all, you didn't really have to change CRC, because it was good enough to detect real-world ripping errors - C2 error correction is very-very-very unlikely to produce isolated errors.

But in case you absolutely had to, my advice was to use CRC32, which is proven to be immune against burst 32-bit errors, random 2-bit errors and most 3-bit errors AND allows offset calculations.

Or you could use Fletcher-32 (http://en.wikipedia.org/wiki/Fletcher%27s_checksum#Optimizations), which is exactly what you in fact tried to do, but done right.

Some useful discussion of checksum properties (http://www.mcabee.org/doc/compressed/internet-drafts/draft-cavanna-iscsi-crc-vs-cksum-01.txt)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-05-16 18:51:50
Quote
And when verifying with AR v2 you can only use CRCs from the same pressing as yours.

That doesn't sound good, specially when the first thing I learned from accuraterip is the incredible number of offseted clones, which is far beyond what I would have imagined.
Presented this way, it sounds like a truncated AR for no gain. I don't know why you're even wasting time implementing it if you're convinced it's not done correctly.

It would be nice if you could agree together, cauz from an external point of view it seems AR2 will be a source of conflict. I think I have already seen Greynol vs Spoon, I don't want to see Gregory vs Spoon. It sounds dumb to me as from a technical point of view, all of you are way above the average HA user like me which don't understand much... I fell like I am counting stars waiting for the battle to end.

Is there a chance that the implementation of AR v2 in cuetool will actually prove who is right & who is wrong ? I mean if a rip is accurate with v1 & not with v2 (or the contrary) or some kind of unexpected behavior like this. [I mean if you consider it bad & you still implement it, I suspect you only implement it to prove that v2 is wrong]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-16 19:46:35
I only implement it because it's very likely that new CDs will only have ARv2 CRCs in database when EAC 1.0 will be officially released, and people will still want to be able to verify their rips.

I need not prove anything. It's the claim that ARv2 is at least in some sense better than ARv1 that needs proof.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2011-05-17 06:48:46
How do I turn off this checking?
(http://i12.fastpic.ru/big/2011/0517/f6/987c9acdd5c8a00169603a01863d1df6.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-17 07:46:25
Click this icon: (http://s57.radikal.ru/i157/1105/80/319af8dc02e2.png)
I know, it's annoying, was a mistake.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-05-17 08:53:44
Quote
Verifying against CRCs from several pressings would require the application to detect those pressing offsets in advance using magic 450th frame CRCs, and then calculate CRCs for all of those offsets independently, decreasing verification speed by an order of magnitude. I will not implement that in CUETools, it's just too slow.


That is how you are supposed to do it, dBpoweramp R14 does this and by doing this the detection is not weakened by side by side calculating every crc and comparing, just the specific ones that the offset crc has highlighted. I think R14 limits to 20 calculations in the back ground, which even a Pentium 3 could do when ripping at x30


Quote
First of all, you didn't really have to change CRC, because it was good enough to detect real-world ripping errors - C2 error correction is very-very-very unlikely to produce isolated errors.


I have tested drives where C2 pointers are incredibly weak, almost as though there are not there (let so many errors through undetected). C2 cannot be relied on for all drives.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-05-17 08:56:21
>That doesn't sound good, specially when the first thing I learned from accuraterip is the incredible number of offseted clones, which is far beyond what I would have imagined.

AccurateRip v2 does detect across pressings
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-17 09:19:43
That is how you are supposed to do it, dBpoweramp R14 does this and by doing this the detection is not weakened by side by side calculating every crc and comparing, just the specific ones that the offset crc has highlighted. I think R14 limits to 20 calculations in the back ground, which even a Pentium 3 could do when ripping at x30

CUETools doesn't rip, and currently it's AR verification speed is limited only by flac decoding or HDD speed. That wouldn't be so when doing 10-20 calculations. Also that would also require a needless preparatory stage involving a lot of seeking to find 11 magic frames in each track. That's just bad design. And ARv2 CRC is also a bad design. It's just a broken version of higher bits of Fletcher-64, which has more collisions due to overflows than real Fletcher-64.

The detection is not in any way weakened by using the linear properties of ARv1 CRC (or CRC32 or Fletcher-32). It is mathematically equivalent to do a lot of calculations or one smart calculation, but the latter is much faster. I can always limit the output to offsets indicated by frame450, but i prefer not to do it.

I have tested drives where C2 pointers are incredibly weak, almost as though there are not there (let so many errors through undetected). C2 cannot be relied on for all drives.

I didn't say anything about C2 pointers. I was talking about C2 error correction. When it lets the error through, it's never a single bit error. That's just how Reed-Solomon coding works. So in practice, weakness of ARv1 didn't matter much.

AccurateRip v2 does detect across pressings

In DbPoweramp i assume. As far as i know, not in EAC, not in fb2k and probably won't be in CUETools.

You already made a mistake once by inventing a bad CRC instead of taking 5 minutes to read on the subject. That's understandable, we all make mistakes. But why do the same mistake the second time, ignoring any advice?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-05-17 11:02:48
So switching to CRC32 would have allowed "AR verification speed >which< is limited only by flac decoding or HDD speed."? You cannot have your cake, and eat it too.

I also have never seen a false positive from AccurateRip based on real ripped data (and how many millions of CDs do these respective programs rip?), it should be obvious if the 'crc' was weak, a T&C in EAC (or similar in dBpoweramp) would give different overall CRC32s yet report a static AR CRC **.

If AR is as flawed as you speak, don't use it, I personally do not think it is flawed, yet it seems to be the current craze to bash it.



** the above does happen for tracks where the 5 frames are not taken into account for first or last track, this has been spotted many times and is to be expected.

(note this thread should split as discussions are not overly Cuetools related).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-17 12:04:12
So switching to CRC32 would have allowed "AR verification speed >which< is limited only by flac decoding or HDD speed."? You cannot have your cake, and eat it too.

In fact, you can. Simple table implementation of CRC32 has approximately the same speed as ARv2 CRC. CRC32 on modern processors with SSE4.2 is way faster than ARv2 CRC (the special crc32 instruction introduced by Intel can process up to 64 bit per clock cycle (i.e. 3Ghz processor can process audio data at 146087x ripping speed)  - see here (http://drdobbs.com/high-performance-computing/229401411)). And Fletcher-32 is about as fast as you can get without the special instruction.

If AR is as flawed as you speak, don't use it, I personally do not think it is flawed, yet it seems to be the current craze to bash it.

AR is great. I'm not bashing it. I just think a decision to introduce a new CRC didn't improve it, and the particular choice of a new CRC was very poor.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-05-17 17:03:46
If AR is as flawed as you speak, don't use it, I personally do not think it is flawed, yet it seems to be the current craze to bash it.

"Bashing" wouldn't be the "current craze" if the developer were actually receptive to legitimate criticism and interested in improvement.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2011-05-17 19:49:04
I hate to see this break down into a flame war instead of being a productive discussion. Maybe a completely open standard and protocol would be more helpful?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-05-18 09:54:28
"Bashing" wouldn't be the "current craze" if the developer were actually receptive to legitimate criticism and interested in improvement.


So you are saying I have an obligation to do this?, improve the CRC (although I have never seen a false positive) and all the other waste of time demands (such as detecting the insignificant number of drives which have buggy firmwares).

Ever wondered why projects such as CDex end up left by the wayside? because people are so ungrateful, if you had developed CDex and there have been 80 million downloads, you can expect on a monthly basis to get:

A) Abusive emails,
B) The occasional suing threat / threat of violence (because program XYZ broke my mouse!), expect three or four a year of these,
C) People who assume that because you have spent 1000's of hours writing something, that somehow implies you must spend a few hours helping that individual on a one to one basis, when this does not happen (A above),

The world is made up of many different people, a small % of these people are lets just say, not nice, inconsiderate, creating anything which has wide appeal will bring you into direct contact with those people. The saying goes "if you give a dog a bone, you do not want to hear from the dog if it does not taste nice".




Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-05-18 12:32:39
improve the CRC (although I have never seen a false positive)


I am falling off the line of argument here, in more ways:

- Wasn't AR2 (an attempt at) improving the CRC?
- Would you actually be able to detect a false positive, if there were/is such one?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-05-18 12:54:22
>Would you actually be able to detect a false positive, if there were/is such one?

If people are doing multiple tries on a damaged disc yes, they would show.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-18 13:14:18
Just to clarify my position: i think AR does it's job just fine. The exact properties of it's CRC are almost irrelevant, it doesn't need a very strong or very fast CRC to function. My objections to V2 are mostly theoretical. I even could probably implement in some form cross-pressing verification, it's just very annoying that i will have to waste time on it when it could have been much easier with a normal CRC, and the verification could be much faster. I have no enmity towards Spoon or AccurateRip.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-18 22:49:20
And just to demonstrate the point about collisions in ARv2.

ARv2 takes the 32-bit sample value, multiplies it by the sample number, resulting in 64-bit number, and then adds the higher 32 bits to lower bits.

Now consider for example the 15th sample in a track, and it's possible values.
Code: [Select]
ARv2(15,0x11111111) = 0xFFFFFFFF
ARv2(15,0x22222222) = hi32(15 * 0x22222222) + lo32(15 * 0x22222222) = hi32(0x1FFFFFFFE) + lo32(0x1FFFFFFFE) = 0x1 + 0xFFFFFFFE = 0xFFFFFFFF
ARv2(15,0x33333333) = hi32(0x2FFFFFFFD) + lo32(0x2FFFFFFFD) = 0xFFFFFFFF
...
ARv2(15,0xFFFFFFFF) = hi32(0xEFFFFFFF1) + lo32(0xEFFFFFFF1) = 0xFFFFFFFF

ARv2(15,0x00000001) = hi32(0x00000000F) + lo32(0x00000000F) = 0x0000000F
ARv2(15,0x11111112) = hi32(0x10000000E) + lo32(0x10000000E) = 0x0000000F
...
ARv2(15,0xEEEEEEEF) = hi32(0xE00000001) + lo32(0xE00000001) = 0x0000000F

That is, at least 15 sample values in this location produce the same CRC. At least 14 sample values produce another CRC. I'm too lazy to explore further, but this might be equivalent to loosing 3-4 bits of of this sample.

UPD: Not so lazy:) It gets worse for sample 255...
Code: [Select]
ARv2(255,0x01010101) = hi32(0x0FFFFFFFF) + lo32(0x0FFFFFFFF) = 0xFFFFFFFF
ARv2(255,0x02020202) = hi32(0x1FFFFFFFE) + lo32(0x1FFFFFFFE) = 0xFFFFFFFF
...
ARv2(255,0x0F0F0F0F) = hi32(0xEFFFFFFF1) + lo32(0xEFFFFFFF1) = 0xFFFFFFFF
ARv2(255,0x10101010) = hi32(0xFFFFFFFF0) + lo32(0xFFFFFFFF0) = 0xFFFFFFFF
ARv2(255,0x11111111) = hi32(0x10FFFFFFEF) + lo32(0x10FFFFFFEF) = 0xFFFFFFFF
...
ARv2(255,0x1F1F1F1F) = hi32(0x1EFFFFFFE1) + lo32(0x1EFFFFFFE1) = 0xFFFFFFFF
...
ARv2(255,0xFFFFFFFF) = hi32(0xFEFFFFFF01) + lo32(0xFEFFFFFF01) = 0xFFFFFFFF
That's 255 samples having the same CRC... Basically, the same problem as with ARv1.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-05-18 23:07:09
So you are saying I have an obligation to do this?

No, I believe I was quite clear in what I said.  Anyhow, seeing that neither of us has changed our stance since the last time we butted heads, I think I'll just go with the "if you don't have anything nice to say, then don't say anything at all" approach.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-05-20 10:39:08
Hello there,
a rather simple question for a complicated case:

is it possible to 'verify' against AR/CTDB a Playstation-style cuesheet referencing TWO pre-audio data tracks ? i.e. the first playable audio CD track starts at #3.

All my attempts at it have failed so far, since only the first referenced data track is detected and thus the generated AR record has no match.
Out of despair I'm starting to experiment with alternative cuesheet designs, file based vs. track based, compliant or not, messing with pregaps and stuff...

Overview of the CD TOC, first few lines:
Code: [Select]
Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 |  7:06.02 |         0    |    31951    <= that's data
        2  |  7:06.02 | 21:19.06 |     31952    |   127882   <= still data
        3  | 28:25.08 |  2:12.33 |    127883    |   137815   <= here we go with audio!



(This 2 pre-audio track thing is such a glorious idea...)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2011-05-22 08:31:18
OK, so now you are getting the same errors I reported earlier on the thread.
I dont know the reason for those errors, they are probably related to .NET 4.0.
Try this code instead, it works for me:

Code: [Select]
if (processor.PreGapLength != 0)
return processor.WriteReport();;
foreach (uint gap in new uint[3] {32, 33, 37})
{
processor.PreGapLength = gap;
processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
}
return processor.WriteReport();



Does this really work for you?
When testing on a rip with known 37 pregap and present in AR database, first it shows greyed AR icon for a while, then for just a fraction of second
I can see it has found match but then stops with batch log result: AR: disk not present in database.
So it seems to be close to doing what it should but something is missing.
Any idea?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-05-23 01:13:29
So it seems to be close to doing what it should but something is missing.
Any idea?


See [a href='index.php?act=findpost&pid=707559']this message[/a]

Perhaps the missing parts?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-05-23 01:18:51
I saw some discussion about this somewhere else. How can all the tracks return "(0/0) No match but offset" ?

Code: [Select]
[CUETools log; Date: 4/29/2011 1:59:20 PM; Version: 2.1.1]
[CTDB TOCID: gFCqM0DjKCCUX0sr_Hee.snk.mE-] found.
        [ CTDBID ] Status
        [1998766c] (4/4) Accurately ripped
[AccurateRip ID: 001c6798-011d7713-ac0d620d] found.
Track  [ CRC    ] Status
 01    [68f1f565] (0/0) No match but offset
 02    [3dc5d93d] (0/0) No match but offset
 03    [559a9dcc] (0/0) No match but offset
 04    [a4a4ba22] (0/0) No match but offset
 05    [83f4349b] (0/0) No match but offset
 06    [b5a142ff] (0/0) No match but offset
 07    [74e00357] (0/0) No match but offset
 08    [54efd8f2] (0/0) No match but offset
 09    [eb152ab6] (0/0) No match but offset
 10    [7372a99c] (0/0) No match but offset
 11    [8c120f5b] (0/0) No match but offset
 12    [aee4e5a8] (0/0) No match but offset
 13    [65b0e952] (0/0) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  99.8 [C01A9145] [49C4FCD1]         
 01  99.8 [CBD678A6] [A9EEAD84]         
 02  99.8 [3545F77C] [17F572CA]         
 03  93.3 [45584278] [E5EC2DFD]         
 04  98.5 [36AB01C5] [477BC49D]         
 05  97.7 [5D4E7C2B] [B783D705]         
 06  99.2 [CBDD28B0] [6ADC932A]         
 07  98.8 [67DA1B68] [355E3F04]         
 08  99.8 [741C13E7] [A0FCA76B]         
 09  98.1 [28046873] [74213A74]         
 10  99.8 [BBCB1F02] [D323A234]         
 11  97.7 [8B74D3EC] [B4F94215]         
 12  99.4 [AD9FD8B2] [E6175469]         
 13  99.8 [C9E0F028] [971B67E5]         
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2011-05-23 06:33:18
So it seems to be close to doing what it should but something is missing.
Any idea?


See [a href='index.php?act=findpost&pid=707559']this message[/a]

Perhaps the missing parts?


Thanks. One day I must find the time to read through the whole thread.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-05-23 16:39:36
I saw some discussion about this somewhere else. How can all the tracks return "(0/0) No match but offset" ?


IIRC that is either due to past aggressive cleanup of the AR database (?) or, more likely, when only two conflicting rips have been submitted to the DB and thus await resolution by a third one.
I have a small number of rips that return such a "(0/0) No match but offset" or "(0/0) Rip not accurate"... which sounds a bit counterintuitive indeed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-23 17:21:35
is it possible to 'verify' against AR/CTDB a Playstation-style cuesheet referencing TWO pre-audio data tracks ? i.e. the first playable audio CD track starts at #3.

I never saw such strange discs, so it's untested. How is cuesheet supposed to look like in this case? Can you send me the cuesheet and eac log?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2011-05-23 17:28:58
when only two conflicting rips have been submitted to the DB and thus await resolution by a third one.


But in that case, it returns just "(0/0) No match" as there is no checksum data available to compare to.

A "(0/0) No match but offset" result indicates there is some data for comparison, but why the 0/0 then? Mind boggles 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-05-25 21:59:40
I apologize if this is completely nonsense... but I don't know... with all the discussion about AR/CueTools databases. Why can't the internal checksums be used for verification. Since this info is already stored there would be no need to process the audio again (lot faster)
and it should be more accurate (md5 128 bit vs 32 bit).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-25 22:42:34
32 bit checksums are quite enough. But you do have a good point about not having to process the audio again. Unfortunately, this won't work, and there is a number of reasons for that.

1) This would require a CD drive to support overread into leadin/leadout, else some leading or trailing samples are lost and hash changes.
2) If the database was track based, you'd have to keep your rip as separate tracks for this to work, and if it was disc image based, you'd have to keep your rip as an image.
3) You'd have to store your files in a format that does have an md5 hash, i.e. no WAV, no ALAC, probably no WMAL... And even in FLAC it's optional.
4) You wouldn't be able to compare your rip with a different pressing.
5) You'd still want to be sure that audio does indeed match the hash.

Frankly, i don't like the fact that FLAC uses md5 hash and i am sometimes tempted to propose to get rid of it (you can, because it's optional) and replace it by some tag containing a good checksum like CRC32. The reason for that is that md5 is the only part of FLAC encoding process that cannot be parallelized. In the age of GPUs and multicore processors that is unacceptable. For example, FLACCL's encoding speed is already limited by md5 calculation speed.

Hash functions should be used for cryptography, not for data integrity checks. They are slow and non-parallelizable. They are meant to protect against deliberate tampering, not hardware/software failures. They have their uses in DRM, but are out of place in open formats like FLAC. md5 as a checksum is not stronger than CRC128, but is slower. And it's an overkill. I would expect FLAC to use Fletcher-16 for frame CRCs and CRC32/64 for file CRC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-05-26 00:09:40
Quote
I would expect FLAC to use Fletcher-16 for frame CRCs and CRC32/64 for file CRC.


Stupid question, (maybe going a little offtopic) would it be noticeably faster on single core CPU too ?

I ask cauz I think I recall that I compared TAK with Flac in the past & I noticed that (IIRW) TAK encoding was mainly much faster than Flac due to the fact that TAK doesn't output MD5 sum by default while Flac does it by default. Once I enabled MD5 in TAK I think I recall the encoding speed difference wasn't so important anymore. (TAK was likely still a little faster, but not as incredibly faster as some test which compare TAK vs. Flac at default setting without caring for MD5. Indeed TAK compression was still 1or1.5% smaller/better.)

I ask cauz as a flac user I would enjoy that the encoding speed gap between Flac & Tak at default [so Flac(With MD5) vs. TAK(Without MD5)] would be reduced ... TAK would still win by a good margin on compression, but the encoding speed comparison would be more fair IMHO.

I mean if it would really work as you say, & more if it's faster on single core too (A slow Sempron 3000+ user like me cares a lot about speed!!!), it would be an interesting improvement to Flac ... well if Josh still knows how to code for Flac  & if he reads CT topics which I doubt anyway ;(

In the end, I think MD5 audio sums should still be available in Flac (just not as the default sum if there is a more efficient alternative as you think), because the main other lossless codecs offer it, because it works & just in case your solution wouldn't work
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-05-26 00:32:48
Thanks for the answer and all the information. It's very clear now. I wasn't aware as well of the md5 performance issues...

Edit: about the checksum used, should be "proof of" incorrect ripping settings? IIRC I have read in some threads that some errors may go unnoticed due to this (like C2 correction). Personally I plan to re-rip many albums based on this (though they are reported as accurate by AR), but "in a more perfect world" if they pass AR/Cuetools verification it shouldn't be necessary.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-05-26 08:38:40
Edit: about the checksum used, should be "proof of" incorrect ripping settings? IIRC I have read in some threads that some errors may go unnoticed due to this (like C2 correction). Personally I plan to re-rip many albums based on this (though they are reported as accurate by AR), but "in a more perfect world" if they pass AR/Cuetools verification it shouldn't be necessary.


I wouldn't worry too much. Yes there are chances for collisions due to weak CRC, but as Gregory points out, there is no deliberate tampering of data -- the errors are drawn random (subject to passing the drive's error corrections). Yes a few samples at the ends are cropped off too. (You might want to notice that e.g. EAC runs through the ripping procedure first, and checks against AccurateRip afterwards. dBpoweramp, on the other hand, invokes no secure reading mode if a burst rip is reported Accurate.)

If you still worry, then run them through the Cuetools database, which is disc based.

If you still want to re-rip a few discs after this, I would assume that you need to use a different drive in order to detect differences. And «different drive» -- you could probably sort this out, but there are many drives that are so similar in actual spinner and firmware, that you could risk picking up just another CD-ROM drive reading the same way. Now you might want to ask «how likely is that?», but bear in mind that we work under the assumption that AR is not accurate enough. You think «drive collision» is less probable than «CRC collision»?
But let us now assume that you then find a bit-different rip where both new and old rip were reported Accurate: How do you tell which one is wrong? Multiple issues will hit you then:
- Lead-in/lead-out. You could probably sort this out from knowledge of the drives.
- Manufactoring errors. It might simply be that the disc has errors which there is no «single true» way of reading. Presumably that is the case I found here: http://forum.dbpoweramp.com/showthread.php?p=88265 (http://forum.dbpoweramp.com/showthread.php?p=88265) .
- Trying a 3rd drive to judge between the two? Bigger chance that this is a rebadge of, or something working identical as, one of the two others.


My suggestion: scrap the re-ripping at least until you want to sell the CDs (edit: or until you find something audibly suspicious)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nassoo on 2011-05-26 15:45:14
Hi! Thanks for the great software!
I have may be stupid question, but... There is an option "Write extraction log to 'LOG' tag"... so, after encoding completed, i don't see this LOG tag in the files... where do i go wrong?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-05-26 16:35:10
when only two conflicting rips have been submitted to the DB and thus await resolution by a third one.


But in that case, it returns just "(0/0) No match" as there is no checksum data available to compare to.

A "(0/0) No match but offset" result indicates there is some data for comparison, but why the 0/0 then? Mind boggles 


OK I rechecked 4 discs that came up "(0/0) No match but offset" in v2.1.1 and they come up "(0/0) No match" in v2.0.9!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-05-26 16:46:35
Hi! Thanks for the great software!
I have may be stupid question, but... There is an option "Write extraction log to 'LOG' tag"... so, after encoding completed, i don't see this LOG tag in the files... where do i go wrong?


I think you'll need to provide more info about what type of file and what you're using to view the tags.
There are two such check boxes, one in 'verify' and one in 'encode and verify'. Having the wrong one checked for the process you're using will make a difference.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: liquefied on 2011-05-26 20:12:01
Also, does this support AccurateRip v2?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-05-26 20:35:01
Also, does this support AccurateRip v2?


In the next release. [a href='index.php?act=findpost&pid=755982']See this.
[/a]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-26 20:39:47
I have may be stupid question, but... There is an option "Write extraction log to 'LOG' tag"... so, after encoding completed, i don't see this LOG tag in the files... where do i go wrong?

This option tries to locate EAC log and place it as a tag into resulting file.
For this to work, EAC log should be in the same folder as the source files, and preferably have the same filename as a CUE sheet.
CUETools will try to locate it even if there are several logs and/or the filenames don't match, but it can do this only if those logs are from a version of EAC that puts CD Table Of Contents into the log file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-26 20:42:52
OK I rechecked 4 discs that came up "(0/0) No match but offset" in v2.1.1 and they come up "(0/0) No match" in v2.0.9!

This could be the result of AR database cleanup. There are offset-detection CRCs in this entry, but no AR CRCs.
But there might be a chance that there are only ARv2 CRCs for this CD. Wait for CUETools 2.1.2 to find out.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-05-26 22:16:04
dBpoweramp, on the other hand, invokes no secure reading mode if a burst rip is reported Accurate.)

So it's strategy is that if there is an error, AR would detect it, in the mean time the rip is faster. Unfortunately I'm not entirely familiar with dBpoweramp yet.

Switching drives is an option, but I was a bit less ambitious  Same drive but different ripping settings. Bottom line is how likely is that some discs may have undetected errors? IMHO I don't like leaving things to chance. Though if the chance of undetected errors is very* very unlikely I wouldn't worry.

Manufactoring errors. It might simply be that the disc has errors which there is no «single true» way of reading. Presumably that is the case I found here: http://forum.dbpoweramp.com/showthread.php?p=88265 (http://forum.dbpoweramp.com/showthread.php?p=88265) ."

So now I understand those results. I initially thought they were slightly different discs/releases.
Also a from the thread that doesn't apply to the thread case, but more to this one.
Quote
It would be interesting to do a series of tests in EAC to see if you could get both AR results on that track from the same disc by tweaking the EAC settings.

So let's say this case scenario

1. A rip with burst mode and other incorrect settings.
2. Same disc rip with secure mode/correct settings.
3. Both rips have different CRC128/64.
4. AR/Cuetools databases report both as accurate.

How likely or unlikely is 4 (as well as 3)?
I wish there was some sort of study on the matter, but considering all the factors (different rip settings, drives, etc) that may be overkill.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-05-27 01:11:05
So let's say this case scenario

1. A rip with burst mode and other incorrect settings.
2. Same disc rip with secure mode/correct settings.
3. Both rips have different CRC128/64.
4. AR/Cuetools databases report both as accurate.

How likely or unlikely is 4 (as well as 3)?



I am not completely sure what you intend to do.  Let me be a total devil's advocate here, and make the worst-possible interpretation -- not because I think it is correct, but it might explain what can go wrong.


What makes AR/Cuetools verification go round, is basically the assumption that an erroneous rip will hardly ever match anything, because it gives a checksum at random -- if we are lucky, not too many orders of magnitude away from a uniform draw. Now if you tweak a setting (like, channel reversal), this is a error that someone else can plausibly have made before you on that disc.

Now you have two events which might trigger an erroneous "Accurate":
- there is a scratch, but the wrong sample does by chance evaluate to an AR match
or
- the CD is otherwise correct, but by human error, someone else has done the same settings mistake as you have
(or both)

I would guess that the latter event is more likely.

Now if you are even tweaking the settings around, it looks like you are deliberately chasing "has someone else done this mistake before me?". That's not what you want. Besides, that's not what anyone else wants -- you are offering a false "Accurate" to the next person who accidentally makes the same settings mistake.



So ... if you might correct my interpretation ...?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-05-27 18:55:57
uh I'm not intending to chase anyone... 
The case actually applies to me...
I ripped with incorrect settings many albums, most were reported as accurate.
If I re-rip them again and compare both rips with a checksum verification tool, chances are they are both the same (considering that I used the correct offset in both rips). The other alternative is that the checksum verification (like CRC 128bit), reports differences between tracks of the two rips. That would most likely indicate that the first rip was different/inaccurate though it was reported as accurate and maybe shared the same AR/CTDB checksum. My question is how likely/or maybe possible is that this can happen.

In others words, up to what point I should be confident that my old rips would pass a CRC 128bit verification/be identical to re-rips with correct settings, or not.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-27 23:08:30
So let's say this case scenario

1. A rip with burst mode and other incorrect settings.
2. Same disc rip with secure mode/correct settings.
3. Both rips have different CRC128/64.
4. AR/Cuetools databases report both as accurate.

How likely or unlikely is 4 (as well as 3)?

Normally there's a roughly 2^(-32) chance (1 disc out of 4294967296), assuming the errors in burst mode were random.

It's hard to estimate the chance of non-random errors which could in theory be caused by CD-drive's firmware or something like that, when the database can contain a CRC from someone with the drive which has exactly the same problem. But you can probably be sure this didn't happen to you if AR confidence level was high enough, because the majority of submissions would be made using different drives that are unlikely to have exactly the same bug.

There's a quite high probability that the CRC of the complete image will differ, when there are problems reading the first or the last few samples of the disc, which AR/CTDB deliberately ignore.
This shouldn't worry you, however, because those are small areas and usually are very close to silence, so those errors won't be audible.

To cut the long story short: you can trust AR if confidence levels are 'high enough'. You'll have to determine that 'high enough' level for yourself depending on how paranoid you are.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nassoo on 2011-05-28 12:02:13
Hello again!
I'm still a newbie with this tool, so I need a little help... I'm trying to verify my flacs (with no cue file). For some of them, after the verification, the tags look like this:

ACCURATERIPCOUNT = 0
ACCURATERIPCOUNTALLOFFSETS = 147
ACCURATERIPCOUNTWITHOFFSET = 177
ACCURATERIPTOTAL = 165

I suppose this means the rip is not accurate?
My question is about ACCURATERIPCOUNTALLOFFSETS and ACCURATERIPCOUNT - which one shows if the rip is accurate?
When the result in CueTools is "AR: rip accurate (30/33)", which tag corresponds to the first number (30 in this case)?
I'll be grateful if you can point me where I could read a detailed description of the exact meaning of this tags.

Thank you in advance!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2011-05-28 12:13:09
enable the "batch log" pane (button to the left of the preferences "cog" button). then change the "input" section to "local database". then find the album and highlight it, then you'll see the full log in the bottom pane and you can see how the numbers correspond with the tags.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-28 13:56:23
When the result in CueTools is "AR: rip accurate (30/33)", which tag corresponds to the first number (30 in this case)?

AR: rip accurate (ACCURATERIPCOUNTALLOFFSETS/ACCURATERIPTOTAL)
EAC shows (ACCURATERIPCOUNT/ACCURATERIPTOTAL).
ACCURATERIPCOUNTALLOFFSETS is the sum of confidence against all pressings.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-05-28 16:25:37
So you are saying I have an obligation to do this? [...] The saying goes "if you give a dog a bone, you do not want to hear from the dog if it does not taste nice".


Just a very few points in here.

1) Generally speaking, I think that «listen to good advise» is good advise, obligation or not.

2) ... and I think Spoon did -- or attempted to do -- just that. Take a look at http://www.hydrogenaudio.org/forums/index....showtopic=61468 (http://www.hydrogenaudio.org/forums/index.php?showtopic=61468) .

3) Gregory, you did contribute on the matter (posting #53 and later), and from what I can see, you supported the current choice of checksum, right? (#57). If the checksum is still flawed then well, too bad, but it is not because it was chosen without consulting the Hydrogenaudio braintrust.

4) For an "AccurateRip 3" to be feasible now, I think the following three considerations are relevant: (I) is AR2 fundamentally flawed?, (II) is «anyone» yet using AR2?, (III) what are the costs of actually correcting it?. For (I), I think the relevant benchmark is «how bad is this compared to the weakness which as a matter of fact did trigger an update?», (III) I leave to you coders (Gregory, you could maybe even give Spoon a cutandpastable codebone here?  ), and for (II) ... well, I do not know. AR2 support found its way into EAC last November, so it might be too late to be a good option?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2011-05-28 19:20:19
3) Gregory, you did contribute on the matter (posting #53 and later), and from what I can see, you supported the current choice of checksum, right? (#57). If the checksum is still flawed then well, too bad, but it is not because it was chosen without consulting the Hydrogenaudio braintrust.


The current choice of format is not CRC32. Gregory supported CRC32 against hashes. Please read #63.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-05-28 19:37:16
3) Gregory, you did contribute on the matter (posting #53 and later), and from what I can see, you supported the current choice of checksum, right? (#57). If the checksum is still flawed then well, too bad, but it is not because it was chosen without consulting the Hydrogenaudio braintrust.

I was against the whole idea of introducing a new CRC (#53), and in case it was decided to introduce a new CRC, i advocated the use of CRC32 (#53, #57, #63). I said (#63) that new CRC is not much better than the old one. But there's not much point in bringing it all up now. What's done is done, i don't think that it can easily be reversed.

4) For an "AccurateRip 3" to be feasible now, I think the following three considerations are relevant:
(I) is AR2 fundamentally flawed?, (II) is «anyone» yet using AR2?, (III) what are the costs of actually correcting it?.

I) No, it's not. And AR1 was not.
II) When i verify my rips with ARv2-supporting version of CUETools, i see quite a lot of AR2 CRCs. Probably around 5-10 percents of the database are V2 CRCs.
III) If it was to be replaced with CRC32, that would be very easy to implement in CUETools. Much-much simpler than to implement cross-pressing verification for AR2 CRC.

Gregory, you could maybe even give Spoon a cutandpastable codebone here?

CRC32 is very well known and it's implementations are all-over the place.
I already did provide a link to efficient Fletcher-32 CRC code - it's based on the same idea that AR2 CRC, but without the bug and is a bit faster:  http://en.wikipedia.org/wiki/Fletcher%27s_...m#Optimizations (http://en.wikipedia.org/wiki/Fletcher%27s_checksum#Optimizations)
But it's a little bit too late for that.

At this point, my first choice would be to just drop ARv2 CRC and revert back to ARv1 CRC, and purge all ARv2 CRCs from the database if it's possible. Just to keep things simple.
My second choice would be to do nothing and live with ARv2. It's ugly, and doesn't support cross-pressing verification too well, but it works.
My third choice would be to purge all ARv2 CRCs from the database and switch to CRC32, just to stop all the speculations about the perceived "flaws" in AR.
Fletcher-32 would be my last choice. It's a quite strong and very fast CRC, but it doesn't have to be that strong or that fast, and it's not a very well-known CRC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2011-05-28 20:03:12
Let me guess... Spoon chose to work on his own implementation due to marketing reasons.
BTW, the whole AR idea was great and all credits go to Spoon, and secondly, to Gregory for extending this concept.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-05-29 00:02:49
Lets talk a little about perceived flaws in AR2...yes on very small datasets you can simulate collisions more readily than a CRC32, but I do not think this is true once a large amount of data passes through either (and any track on a CD is a large amount of data).


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-05-29 17:17:53
Lets talk a little about perceived flaws in AR2...yes on very small datasets you can simulate collisions more readily than a CRC32, but I do not think this is true once a large amount of data passes through either (and any track on a CD is a large amount of data).


Given that we have a "large amount of data" (i.e. a full track), and given also some «realistic drive behaviour», then it would be a good thing to have at least some partial knowledge of what errors are possible, plausible and likely.

A very particular example: I guess you guys know fairly well how drives interpolate missing samples. So I would suppose that a likely erroneous sample delivered from the CD drive, is the interpolated value. So the «distribution of erroneous samples» should be expected to be far from uniform.

How often could such an error (assuming that the true value is not by coincidence equal to the interpolated!) lead to a collision? (The answer does possibly depend on what is the distribution in real music of "middle samples" given the two neighbours.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-05-29 19:39:32
Thanks again. I should have studied CRC tech specs... now I did.
You'll have to determine that 'high enough' level for yourself depending on how paranoid you are.

IMHO = or > 2 or if the number of matches is the highest, seems right.

Thanks for taking the time.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-06-01 13:24:18
A minor feature request if I may:

could it be possible to provide a general setting to "always overwrite" files, or perhaps only non-critical files (e.g. .accurip, .log, .cue...)? The setting checkbox which pops up at run-time allows overwriting files during a batch job but is not remembered between or within subsequent sessions.

(Or perhaps did I overlook something...)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2011-06-02 15:25:42
Summary: .accurip says rip is accurate, and if you compare .accurip CRC32 values to .log CRC values each track matches, but .accurip says that CRC32 values don't match for some tracks.

Using CueTools 2.0.9, I ran a Verify on a recent rip, and the result is puzzling. The .accurip report generated by CueTools says that the rip is accurate, but the bottom section says that the CRC32 values for tracks 5-9 don't match the CRC values for same tracks in the log, but instead match other track numbers. This is very strange.

Quote
Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
--  95.3 [B32808E7] [942C824D]
01  89.6 [82FBCB38] [97D51307]  CRC32
02  87.2 [F88E3C98] [BB1556DD]  CRC32
03  89.5 [B3BB9AC3] [6C8DE019]  CRC32
04  90.6 [BA3FCC92] [B6938BD8]  CRC32
05  92.1 [73266BBC] [C902FE6B] [71E0C6B3]: CRC32 for track 6
06  83.9 [71E0C6B3] [7CF02AB2] [EA5530EF]: CRC32 for track 8
07  90.5 [67E5854C] [8C6E2362] [CE06ED2E]: CRC32 for track 9
08  93.1 [EA5530EF] [F3CAC94F] [73266BBC]: CRC32 for track 5
09  95.3 [CE06ED2E] [88EA19E5] [67E5854C]: CRC32 for track 7


However, when I check for myself by reading the two documents, the CRC32 values shown in the .accurip report do match the CRC values in the log for every track.

Is this some bug in CueTools? Has CueTools somehow become confused on this particular comparison? What is going on here?

Below are the full .accurip report and .log.

.accurip report
Quote
[CUETools log; Date: 02/06/2011 9:31:03 AM; Version: 2.0.9]
[CTDB TOCID: TdM8HPYZNBzW2K9i4Rxd8q7hDRE-] disk not present in database.
[AccurateRip ID: 0013ddc8-00918ae5-770d7809] found.
Track  [ CRC    ] Status
01    [e485c1f8] (17/60) Accurately ripped
02    [5c99a1ef] (17/59) Accurately ripped
03    [53b76232] (17/62) Accurately ripped
04    [88c50190] (17/60) Accurately ripped
05    [e3566cab] (17/61) Accurately ripped
06    [054a1dbf] (17/62) Accurately ripped
07    [8cafe5ba] (17/62) Accurately ripped
08    [2205f363] (17/60) Accurately ripped
09    [e29ccfac] (17/59) Accurately ripped
Offsetted by -664:
01    [e29e85e0] (02/60) Accurately ripped
02    [ff76a437] (00/59) No match
03    [dffd9922] (02/62) Accurately ripped
04    [c9f6d8d0] (00/60) No match
05    [5d9065db] (02/61) Accurately ripped
06    [2cc4bd7f] (02/62) Accurately ripped
07    [f105bc7a] (02/62) Accurately ripped
08    [68293fc3] (00/60) No match
09    [05d63d34] (00/59) No match
Offsetted by 331:
01    [863e09f3] (02/60) Accurately ripped
02    [609e5a3e] (02/59) Accurately ripped
03    [1f8680a4] (02/62) Accurately ripped
04    [0ffb3268] (04/60) No match but offset
05    [58876795] (02/61) No match but offset
06    [0bd38b07] (02/62) Accurately ripped
07    [dee95922] (02/62) Accurately ripped
08    [e1c23bf7] (02/60) Accurately ripped
09    [67078253] (04/59) No match but offset
Offsetted by 367:
01    [ea962457] (35/60) Accurately ripped
02    [5c6a4612] (37/59) Accurately ripped
03    [99765bbc] (37/62) Accurately ripped
04    [76db3188] (37/60) No match but offset
05    [4590994d] (36/61) No match but offset
06    [59e0f167] (37/62) Accurately ripped
07    [40cc0502] (37/62) Accurately ripped
08    [fccca867] (37/60) Accurately ripped
09    [4dfcaf47] (36/59) No match but offset

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
--  95.3 [B32808E7] [942C824D]
01  89.6 [82FBCB38] [97D51307]  CRC32
02  87.2 [F88E3C98] [BB1556DD]  CRC32
03  89.5 [B3BB9AC3] [6C8DE019]  CRC32
04  90.6 [BA3FCC92] [B6938BD8]  CRC32
05  92.1 [73266BBC] [C902FE6B] [71E0C6B3]: CRC32 for track 6
06  83.9 [71E0C6B3] [7CF02AB2] [EA5530EF]: CRC32 for track 8
07  90.5 [67E5854C] [8C6E2362] [CE06ED2E]: CRC32 for track 9
08  93.1 [EA5530EF] [F3CAC94F] [73266BBC]: CRC32 for track 5
09  95.3 [CE06ED2E] [88EA19E5] [67E5854C]: CRC32 for track 7



.log
Quote
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 1. June 2011, 18:51

Herbie Hancock / Takin' Off

Used drive  : HL-DT-STDVD-ROM DU10N  Adapter: 0  ID: 1

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 102
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format              : User Defined Encoder
Selected bitrate                : 320 kBit/s
Quality                        : High
Add ID3 tag                    : No
Command line compressor        : C:\Program Files\a Accessories\Exact Audio Copy\Flac\flac.exe
Additional command line options : -V -5 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  7:07.72 |        0    |    32096
        2  |  7:07.72 |  5:25.48 |    32097    |    56519
        3  | 12:33.45 |  6:10.42 |    56520    |    84311
        4  | 18:44.12 |  6:47.40 |    84312    |  114876
        5  | 25:31.52 |  6:55.58 |    114877    |  146059
        6  | 32:27.35 |  6:27.50 |    146060    |  175134
        7  | 38:55.10 |  6:34.17 |    175135    |  204701
        8  | 45:29.27 |  5:32.00 |    204702    |  229601
        9  | 51:01.27 |  6:27.28 |    229602    |  258654


Track  1

    Filename C:\Rip\01 - Watermelon Man.wav

    Pre-gap length  0:00:02.00

    Peak level 89.6 %
    Track quality 100.0 %
    Test CRC 82FBCB38
    Copy CRC 82FBCB38
    Accurately ripped (confidence 17)  [E485C1F8]
    Copy OK

Track  2

    Filename C:\Rip\02 - Three Bags Full.wav

    Peak level 87.2 %
    Track quality 100.0 %
    Test CRC F88E3C98
    Copy CRC F88E3C98
    Accurately ripped (confidence 17)  [5C99A1EF]
    Copy OK

Track  3

    Filename C:\Rip\03 - Empty Pockets.wav

    Peak level 89.5 %
    Track quality 99.9 %
    Test CRC B3BB9AC3
    Copy CRC B3BB9AC3
    Accurately ripped (confidence 17)  [53B76232]
    Copy OK

Track  4

    Filename C:\Rip\04 - The Maze.wav

    Peak level 90.6 %
    Track quality 100.0 %
    Test CRC BA3FCC92
    Copy CRC BA3FCC92
    Accurately ripped (confidence 17)  [88C50190]
    Copy OK

Track  6

    Filename C:\Rip\06 - Alone and I.wav

    Pre-gap length  0:00:01.06

    Peak level 83.9 %
    Track quality 100.0 %
    Test CRC 71E0C6B3
    Copy CRC 71E0C6B3
    Accurately ripped (confidence 17)  [054A1DBF]
    Copy OK

Track  8

    Filename C:\Rip\08 - Three Bags Full [bonus alt. take].wav

    Peak level 93.1 %
    Track quality 100.0 %
    Test CRC EA5530EF
    Copy CRC EA5530EF
    Accurately ripped (confidence 17)  [2205F363]
    Copy OK

Track  9

    Filename C:\Rip\09 - Empty Pockets [bonus alt. take].wav

    Peak level 95.3 %
    Track quality 100.0 %
    Test CRC CE06ED2E
    Copy CRC CE06ED2E
    Accurately ripped (confidence 17)  [E29CCFAC]
    Copy OK


8 track(s) accurately ripped
1 track(s) canceled

Some tracks could not be verified as accurate

There were errors

End of status report

------------------------------------------------------------
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 1. June 2011, 19:19

Herbie Hancock / Takin' Off

Used drive  : HL-DT-STDVD-ROM DU10N  Adapter: 0  ID: 1

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 102
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format              : User Defined Encoder
Selected bitrate                : 320 kBit/s
Quality                        : High
Add ID3 tag                    : No
Command line compressor        : C:\Program Files\a Accessories\Exact Audio Copy\Flac\flac.exe
Additional command line options : -V -5 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  7:07.72 |        0    |    32096
        2  |  7:07.72 |  5:25.48 |    32097    |    56519
        3  | 12:33.45 |  6:10.42 |    56520    |    84311
        4  | 18:44.12 |  6:47.40 |    84312    |  114876
        5  | 25:31.52 |  6:55.58 |    114877    |  146059
        6  | 32:27.35 |  6:27.50 |    146060    |  175134
        7  | 38:55.10 |  6:34.17 |    175135    |  204701
        8  | 45:29.27 |  5:32.00 |    204702    |  229601
        9  | 51:01.27 |  6:27.28 |    229602    |  258654


Track  5

    Filename C:\Rip\05 - Driftin'.wav

    Peak level 92.1 %
    Track quality 99.7 %
    Test CRC 73266BBC
    Copy CRC 73266BBC
    Accurately ripped (confidence 17)  [E3566CAB]
    Copy OK

Track  7

    Filename C:\Rip\07 - Watermelon Man [bonus alt. take].wav

    Peak level 90.5 %
    Track quality 100.0 %
    Test CRC 67E5854C
    Copy CRC 67E5854C
    Accurately ripped (confidence 17)  [8CAFE5BA]
    Copy OK


All tracks accurately ripped

No errors occurred

End of status report

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2011-06-02 15:52:36
CUETools gets confused by "nonstandard" logs, I think it's normal, you can't expect it to be able to parse any kind of weird track order and combination.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-06-02 16:01:24
the bottom section says that the CRC32 values for tracks 5-9 don't match the CRC values for same tracks in the log, but instead match other track numbers. This is very strange.


What Goratrix said. The log file is being read in order from top to bottom, not by track number. The tracks are listed out of order so they don't match up. If tracks 5 and 7 were where they belong, everything would be fine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2011-06-02 16:18:42
The log file is being read in order from top to bottom, not by track number. The tracks are listed out of order so they don't match up. If tracks 5 and 7 were where they belong, everything would be fine.

Ah, okay, that makes sense if that's how CueTools reads the log. Thanks for explaining that, and thanks to Goratrix. Very helpful.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-06-02 21:39:52
I saw some discussion about this somewhere else. How can all the tracks return "(0/0) No match but offset" ?


IIRC that is either due to past aggressive cleanup of the AR database (?) or, more likely, when only two conflicting rips have been submitted to the DB and thus await resolution by a third one.
I have a small number of rips that return such a "(0/0) No match but offset" or "(0/0) Rip not accurate"... which sounds a bit counterintuitive indeed.

Short update on this puzzling "issue", I just noticed one case where all tracks but one are verified as accurately ripped (confidence 2/2), the faulty (?) one shows as "0/0 No match". Seems quite weird.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ThePampers on 2011-06-05 01:12:55
Hi, I have a problem.
I recently ripped some CDs without creating a cue file or log (for testing).
Checking the tracks with Cuetools i see this :

Code: [Select]
[AccurateRip ID: 0010d9b6-0092b069-9809ab0b] found.
Track  [ CRC    ] Status
 01    [ddbaf796] (00/26) No match
 02    [1b6d1bd2] (00/25) No match
 03    [49fa7b44] (00/26) No match
 04    [e3aa907f] (00/27) No match
 05    [ad26832d] (00/27) No match
 06    [1f61e1e9] (00/26) No match
 07    [e89cac08] (00/26) No match
 08    [b4e3847b] (00/26) No match
 09    [8f2c09c6] (00/26) No match
 10    [a5fd5554] (00/26) No match
 11    [d7e5383d] (00/26) No match
Offsetted by 97:
 01    [5c886412] (26/26) Accurately ripped
 02    [5947ff85] (25/25) Accurately ripped
 03    [3fd968b6] (26/26) Accurately ripped
 04    [2d13494a] (27/27) Accurately ripped
 05    [2e7772e4] (27/27) Accurately ripped
 06    [d4f7cae4] (26/26) Accurately ripped
 07    [ff712985] (26/26) Accurately ripped
 08    [668cd35d] (26/26) Accurately ripped
 09    [c297e9bc] (26/26) Accurately ripped
 10    [28fcfb1e] (26/26) Accurately ripped
 11    [ac5e13c7] (26/26) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  98,8 [D0DB84E6] [946F787A]         
 01  98,8 [360A85C1] [4BD6A120]         
 02  94,4 [3B05C5A4] [3F9A9D2C]         
 03  98,8 [CA35FC88] [5C05F1BB]         
 04  98,8 [B9B96159] [06AC6F45]         
 05  96,6 [6D2BDD22] [17B5A1AD]         
 06  96,6 [3CE8E6DC] [12D0F567]         
 07  97,7 [7D2E17CA] [D80DA5D3]         
 08  97,7 [97FBAFFA] [A43B733B]         
 09  98,8 [7AB9CBDB] [5BF4A851]         
 10  98,8 [1B9D17AF] [3AE6C26B]         
 11  98,8 [0026DCEA] [1ADB9BB2] 

Now I have created with Cuetools the correct cue file (+97 offsetted), then burn and re-rip with EAC (last beta 1.02) to verify the integrity.
EAC does not find any tracks correct (CRC data from AccurateRip database) :

Code: [Select]
Exact Audio Copy V1.0 beta 2 from 29. April 2011

EAC extraction logfile from 5. June 2011, 2:20

Sammy Hagar and the Wabos / Livin' It Up

Used drive  : TSSTcorpCDDVDW SH-S223C  Adapter: 0  ID: 0

Read mode : Burst

Read offset correction                      : 697
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Installed external ASPI interface
Gap handling                                : Appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  2:56.72 |        0    |    13271 
        2  |  2:56.72 |  4:20.38 |    13272    |    32809 
        3  |  7:17.35 |  3:34.15 |    32810    |    48874 
        4  | 10:51.50 |  4:39.30 |    48875    |    69829 
        5  | 15:31.05 |  3:41.25 |    69830    |    86429 
        6  | 19:12.30 |  2:18.07 |    86430    |    96786 
        7  | 21:30.37 |  3:37.10 |    96787    |  113071 
        8  | 25:07.47 |  4:23.43 |    113072    |  132839 
        9  | 29:31.15 |  4:21.27 |    132840    |  152441 
      10  | 33:52.42 |  4:24.35 |    152442    |  172276 
      11  | 38:17.02 |  2:58.48 |    172277    |  185674 


Track  1

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\01. Sam I Am.wav

    Pre-gap length  0:00:02.00

    Peak level 98.8 %
    Extraction speed 14.9 X
    Test CRC 5F6459E7
    Copy CRC 5F6459E7
    Cannot be verified as accurate (confidence 26)  [908F7E1E], AccurateRip returned [5C886412]  (AR v2)
    Copy OK

Track  2

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\02. Living on a Coastline.wav

    Peak level 94.4 %
    Extraction speed 20.3 X
    Test CRC 40CFCCDB
    Copy CRC 40CFCCDB
    Cannot be verified as accurate (confidence 25)  [6B9F2E0C], AccurateRip returned [5947FF85]  (AR v2)
    Copy OK

Track  3

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\03. Mexico.wav

    Peak level 98.8 %
    Extraction speed 21.9 X
    Test CRC 2F1CE7EC
    Copy CRC 2F1CE7EC
    Cannot be verified as accurate (confidence 26)  [1A43DF57], AccurateRip returned [3FD968B6]  (AR v2)
    Copy OK

Track  4

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\04. The Way We Live.wav

    Peak level 98.8 %
    Extraction speed 23.6 X
    Test CRC 689321A8
    Copy CRC 689321A8
    Cannot be verified as accurate (confidence 27)  [F346154E], AccurateRip returned [2D13494A]  (AR v2)
    Copy OK

Track  5

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\05. I Love This Bar.wav

    Peak level 96.6 %
    Extraction speed 25.0 X
    Test CRC 772E3055
    Copy CRC 772E3055
    Cannot be verified as accurate (confidence 27)  [19EFCB2A], AccurateRip returned [2E7772E4]  (AR v2)
    Copy OK

Track  6

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\06. One Sip.wav

    Peak level 96.6 %
    Extraction speed 26.0 X
    Test CRC 31918E26
    Copy CRC 31918E26
    Cannot be verified as accurate (confidence 26)  [361532C3], AccurateRip returned [D4F7CAE4]  (AR v2)
    Copy OK

Track  7

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\07. Rainy Day Woman #12,#35.wav

    Peak level 97.7 %
    Extraction speed 27.1 X
    Test CRC 624C4D70
    Copy CRC 624C4D70
    Cannot be verified as accurate (confidence 26)  [7A79873F], AccurateRip returned [FF712985]  (AR v2)
    Copy OK

Track  8

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\08. Halfway to Memphis.wav

    Peak level 97.7 %
    Extraction speed 28.4 X
    Test CRC BAEA4D87
    Copy CRC BAEA4D87
    Cannot be verified as accurate (confidence 26)  [074514C6], AccurateRip returned [668CD35D]  (AR v2)
    Copy OK

Track  9

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\09. Sailin.wav

    Peak level 98.8 %
    Extraction speed 29.7 X
    Test CRC 6761AA6F
    Copy CRC 6761AA6F
    Cannot be verified as accurate (confidence 26)  [7304C855], AccurateRip returned [C297E9BC]  (AR v2)
    Copy OK

Track 10

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\10. Let Me Take You There.wav

    Peak level 98.8 %
    Extraction speed 31.0 X
    Test CRC 070ECDFD
    Copy CRC 070ECDFD
    Cannot be verified as accurate (confidence 26)  [5613D63A], AccurateRip returned [28FCFB1E]  (AR v2)
    Copy OK

Track 11

    Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\11. Some Day.wav

    Peak level 98.8 %
    Extraction speed 32.0 X
    Test CRC 3067D159
    Copy CRC 3067D159
    Cannot be verified as accurate (confidence 26)  [F3E4844A], AccurateRip returned [AC5E13C7]  (AR v2)
    Copy OK


No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

No errors occurred

End of status report

==== Log checksum E7C0D84CE375C7EA0A055F4332ABFD5B95257FD60C77469B46C7080A217A9C48 ====



I can recreate the exact cue file without using the audio CD ?
I have to set something else?
I have to re-rip each disc again?
Thanks in advance  .



Edit : Added log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Nino-kun on 2011-06-09 13:03:05
Your cue file was correct from begining. You just have shifted audio data in wave file. CUETools can shift data in wave file so image become "accurate". And you did it. You don't need write image back to CD. If really want to burn CD and rip it again, you need to set write offset in your burning software, or data will be shifted again and you also don't get "accurate" copy.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-06-10 06:22:54
I noticed a minor inconvenience while verifying multiple folders. If the disc directory contains more than one cue file (flac.cue;wav.cue), the same disc will be verified several times, one for each cue. Maybe the local database may be able to skip this redundant checks? (if "skip recently verified" is selected).
Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-11 11:57:39
Any clue when the new version is coming (I thought it was planned for end of May) ? The AR update of June is up & I would like to update my "not present in database" rips but I would prefer using an updated CT (Specially for the HDCD detection bug). If the implementation of AR V2 is too long, just push it back to next version ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-11 12:03:34
ARv2 support (without pressings) is already implemented. I will try to release 2.1.2 within a week. Sorry for the delay, but i got a bit distracted with CTDB plugin, web site update and switch to cloud hosting.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-11 12:15:39
Ok, thks for the quick anwser. I'm gonna wait then.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-13 22:31:21
CUETools 2.1.2 is ready.
http://www.cuetools.net/install/CUETools_2.1.2.rar (http://www.cuetools.net/install/CUETools_2.1.2.rar)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-13 23:11:50
Welcome to the machine
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2011-06-14 05:40:01
Old changelog is displaying
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-06-14 11:49:02
Hi !

Give a try but can't get it working (crash on transformation), tried other combinations also and crash too.
I think I setup paths to encoder exactly, why the error?
Exception: No process assigned to this object.
See the picture:

(http://img143.imageshack.us/img143/9137/1462011124437.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-14 12:52:44
Old changelog is displaying

You're getting the old changelog from cache, which should expire in a day or two. I keep forgetting to make it purge the cache when switching to a new version.

Exception: No process assigned to this object.

Most likely takc.exe doesn't like the command line arguments and exits immediately.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-14 14:37:46
First impressions: I still miss the old ability to detect HDCD (even just to tag their folder as HDCD) & also the ability to nuke the whole database from within CT (Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".) It happened several times to me that I had to close CT & relaunch CT just because I forgot to erease the local database, considering how slow CT is on startup with a Sempron 3000+, this is annoying.

Currently I am still testing & specially I am keeping an eye on how AR V2 results compares against AR V1 results, as of now I noticed that a small amount of AR(1) rips in AR V2 are simultaneously AR(No match but offset/1) in AR V1 (around 25 rips) ... I don't know if it has any meaning or if it's just random.

These rips looks like this:

Quote
[CUETools log; Date: 14/06/2011 02:53:21; Version: 2.1.2]
[CTDB TOCID: nxnT8rnGFSQh5rqdD5eaD9845y8-] disk not present in database.
[AccurateRip ID: 001478f1-00be6205-a70aa80c] found.
Track  [ CRC    ] Status
 01    [d48a93b6] (0/1) No match but offset
 02    [58465981] (0/1) No match but offset
 03    [7fcb705d] (0/1) No match but offset
 04    [7a3bea39] (0/1) No match but offset
 05    [e8de3d53] (0/1) No match but offset
 06    [9c0a8f87] (0/1) No match but offset
 07    [dc4e6f68] (0/1) No match but offset
 08    [f654d376] (0/1) No match but offset
 09    [39c976cb] (0/1) No match but offset
 10    [1f74f692] (0/1) No match but offset
 11    [b72b7bec] (0/1) No match but offset
 12    [a5de0adc] (0/1) No match but offset
AccurateRip v2:
 01    [eeae9727] (1/1) Accurately ripped
 02    [eddfa49f] (1/1) Accurately ripped
 03    [8ebbbac1] (1/1) Accurately ripped
 04    [ef34e2a4] (1/1) Accurately ripped
 05    [1a591d8e] (1/1) Accurately ripped
 06    [3a29e0cb] (1/1) Accurately ripped
 07    [07aa6aba] (1/1) Accurately ripped
 08    [28eb3df6] (1/1) Accurately ripped
 09    [799aa6fa] (1/1) Accurately ripped
 10    [422877c5] (1/1) Accurately ripped
 11    [7e14f5b4] (1/1) Accurately ripped
 12    [ae742ef0] (1/1) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  97,7 [520F4152] [27D503BE]         
 01  97,7 [331C4236] [FD0E301A]         
 02  97,6 [6B8D6665] [44C65F75]         
 03  97,5 [00837037] [23716875]         
 04  97,6 [FC21450A] [81952DA9]         
 05  97,5 [FA6CBD21] [35F5DBB2]         
 06  97,6 [8B648735] [F6AFEEE6]         
 07  97,5 [D24F5766] [B454C535]         
 08  97,5 [E22C79CF] [D8BBC5FC]         
 09  97,6 [16ECD255] [F80F8B67]         
 10  97,7 [76B19F70] [3352F99A]         
 11  97,5 [9917118D] [C77B975C]         
 12  97,5 [00656567] [32B35828]

Not that it is necessarily suspect, but it feels strange to have the same confidence level with different results on two different databases & on around 25 rips.
Maybe the low confidence itself explains this & it's just a question of habbit. I will see how it behaves on rips with higher confidence later.

Also AR V2 bring a lot of sorting question: should I consider an AR(1) on AR V1 + AR(1) on AR V2 rip as an overall AR(2) on AR V1+V2 ??? Obviously Edit: maybe yes, but then the whole way of sorting results from the local database is broken as the above rip is sorted as AR(0) while it is AR(1) in AR V2. [Edit: Well afterall, maybe not, if the same rip is submitted to AR V1 & AR V2 at the same time ... is it the case ???]

This is a real headeache, I hope there will not be an AR V3, V4, V5 ... cauz the .accurip logs will grow exponential. You already need a degree in archeology to dig thru a 57 pages thread but soon you'll need a degree in cryptography to understand .accurip logs ...

Anyway thks [Edit: A lot] for CT.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-14 14:47:46
I still miss the old ability to detect HDCD

Are you sure it's still broken? Should have been fixed.

Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".

You can do it in a couple of clicks, e.g. by right-clicking on "Local DB"->"by Verification Date"->"Today", etc.

but it feels strange to have the same confidence level with different results on two different databases & on around 25 rips.

Those are not different databases. Those are different CRCs within one database actually. My guess is, that old CRC is still used for offset detection CRCs. So EAC submits ARv1 offset detection CRC and ARv2 full CRC for each track.

I probably should just remove the first (ARv1) part of the log if it doesn't contain any matches and just show ARv2 part.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-14 14:59:20
I re-tested HDCD detection on another rip & it worked. Sorry dunno why it didn't work the first time, it's likely my misstake (I must have compared a V2.1.1 .accurip against the same V2.1.1 log by opening it twice instead of opening the new V2.1.2 log, stupid me). Anyway thks for the fix.

Edit: Also the above rip is sorted as AR(1) not AR(0), so it is in the right category ... sorry lots lots of bullshits is coming out of my mouth today.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-06-14 15:02:17
I still miss the old ability to detect HDCD

Are you sure it's still broken? Should have been fixed.


HDCD detection working here so far. Tested on 10+ rips.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-06-14 20:55:05
Welcome to the machine

Agree.
Thanks for the improved skip as well.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2011-06-17 21:51:32
nice update. i'm really liking the ability to remove individual entries from the local database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-18 01:52:52
Some feedback:
I don't know if AR V2 is really usefull (in term of robustness) but I like that AR V2 results are now displayed. It makes clearer where were those hidden results which I think (IIRC) were only displayed in the total sum of all AR (V1+V2) results so far. So thks for AR V2 support. I didn't found any major clash between AR V1 & AR V2 yet, but I did found several newly accurate rips in my collection thks to AR V2 results

For someone like me, who fix offset to highest, the way AR V2 results are displayed makes it hard to differenciate between rips that need fix & rip that are already with corrected offset ... the first time I tried to "fix" an AR(2) V2 with offset=0 rip because with AR V1 it was "no match but offset" with offset=0, so I was visually tricked by the force of habbit & thought it needed fixing ... It is missleading at first, but I have no suggestion to make it clearer (except different colors between AR V1 & V2 results). I first thought of completly separating AR V1 & AR V2 results, but I don't like the idea as if would make direct comparison between AR V1 & AR V2 results harder, so colors would be more suited IMHO, but I think it would maybe require a more complex .accurip format than text. No easy solution, but this is only a minor issue, specially if you don't fix offsets. With time I will get used to it.

Rips with silent tracks are still not reported as accurate in the batchlog, even if sorted as accurate in the local database. That is annoying as it forces me to use a separate folder for rips with [00000000] tracks. I hope it will be solved at some point so that I can once for good merge my collection.

Also rips with all tracks accurate somewhere (on different pressings) but not within the same offset are sorted as accurate in the local database, even if reported as not accurate in the batchlog.

Exemple: The local database sort this as AR(2) while the batchlog detects that it is not accurate.

Code: [Select]
[CUETools log; Date: 17/06/2011 20:00:07; Version: 2.1.2]
[CTDB TOCID: kBfKSyiTi83oBqEbpS6maqCrCqA-] disk not present in database.
[AccurateRip ID: 0016aaad-00decabe-be0b000d] found.
Track   [ CRC    ] Status
01     [f30e04e0] (0/4) No match
02     [e072886c] (0/4) No match
03     [4018f358] (0/4) No match
04     [6369d2ab] (0/4) No match
05     [8c3c17fe] (0/4) No match
06     [aede529f] (0/4) No match
07     [d8cfdd45] (0/4) No match
08     [7d6a5564] (0/2) No match
09     [0bff9354] (0/4) No match
10     [01fb4662] (0/4) No match
11     [efd8b57c] (0/4) No match
12     [90e6823c] (0/2) No match
13     [c8706114] (0/4) No match
Offsetted by -562:
01     [20ff9cd4] (2/4) Accurately ripped
02     [3319b5e4] (2/4) Accurately ripped
03     [96774600] (2/4) Accurately ripped
04     [df230673] (2/4) Accurately ripped
05     [3c243cf8] (2/4) Accurately ripped
06     [68dc8b9f] (2/4) Accurately ripped
07     [b6c666f1] (2/4) Accurately ripped
08     [64e6347a] (0/2) No match but offset
09     [954b801a] (2/4) Accurately ripped
10     [971f35c0] (2/4) Accurately ripped
11     [66e9b576] (2/4) Accurately ripped
12     [d81027ce] (2/2) Accurately ripped
13     [751e2c02] (2/4) Accurately ripped
Offsetted by 36:
01     [17493f78] (2/4) Accurately ripped
02     [f592a47c] (2/4) Accurately ripped
03     [0214bb08] (2/4) Accurately ripped
04     [05d9dc1b] (2/4) Accurately ripped
05     [1a05234a] (2/4) Accurately ripped
06     [4c68009f] (2/4) Accurately ripped
07     [ba31f36d] (2/4) Accurately ripped
08     [353133f8] (2/2) Accurately ripped
09     [c540dc88] (2/4) Accurately ripped
10     [414f8566] (2/4) Accurately ripped
11     [1df86ac8] (2/4) Accurately ripped
12     [46314758] (0/2) No match but offset
13     [9f504af8] (2/4) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--  100,0 [DDD04840] [022FCAD7]          
01  100,0 [42F0161D] [3C469549]          
02   97,6 [698FEA12] [82548A2F]          
03   97,6 [400BABDA] [8F8A082D]          
04   50,3 [242F015B] [14CA512E]          
05   97,6 [8646E8D0] [618049AB]          
06   97,6 [7A0A51AF] [23ECABEA]          
07   97,6 [6AA93766] [31CD105D]          
08   97,6 [06B05B5D] [F5ABD106]          
09   97,6 [44CCA0E3] [B17A8FBF]          
10   97,6 [D2F0761E] [F25C4E32]          
11   97,6 [34377520] [AC8F9514]          
12   97,6 [84B6BD90] [53073C6A]          
13   97,6 [F2CC8154] [D8E78A67]


Edit:
Also, it would be nice if there would be an option to keep the "Desktop" tree always unexpended because when you switch from "Drag&Drop mode" to "File browser mode" after a verification, it is always expended (to the last tested rip IIRC) & it is annoying as if you use "Drag&Drop mode" to add files/folders then you don't use the "File browser mode", this is an annoying side effect of merging "local database" with "File browser mode" ... I always have to click "desktop" to unexpend/hide it & this is annoying as hell.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-18 09:46:43
Even better than a don't expend "desktop" option: why not just display the "local database" in "drag & drop mode" too, just like you did for the "File browser mode", this way I wouldn't even have to always switch between the two view styles & would save 2 clicks after each verification.

The "drag & drop mode" only take 1 line so there is plenty of room to display the "local database" there. Nothing said the "local database" has to be attached to 1 view style/mode only.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Galsia on 2011-06-18 14:42:23
Thanks for this new version, something about it is bothering me though.

In previous versions after choosing the "encode" action, it was possible to select a tracklist coming from a cue sheet or online databases and to edit it along with album data (artist, album, date, etc.). It was then saved to tags and locally, so it was possible encode the same album again without re-editing metadata. In this version there are more fields (which is nice since I use most of them), but edits aren't saved in tags or locally anymore. Is it intended, or am I missing something?

Also it would be nice to have the catalogue number in a different field than the label.

Anyway, thanks again for your work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Balleklorin on 2011-06-19 11:28:29
Thanks for this new version, something about it is bothering me though.

In previous versions after choosing the "encode" action, it was possible to select a tracklist coming from a cue sheet or online databases and to edit it along with album data (artist, album, date, etc.). It was then saved to tags and locally, so it was possible encode the same album again without re-editing metadata. In this version there are more fields (which is nice since I use most of them), but edits aren't saved in tags or locally anymore. Is it intended, or am I missing something?

Also it would be nice to have the catalogue number in a different field than the label.

Anyway, thanks again for your work.


Same problem here. Hope it will be fixed soon.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thescribbler on 2011-06-19 12:22:30
Hi,

First off, thanks for such a great tool!

I have a weird problem that has only appeared since I did a fresh install of XP.

I have been going through my music library and using Cuetools to correct file/track names and split my single file rips into multiple files. Normally, when I want to correct file/track names, I create a new folder and re-encode the album into that. When I click 'Go' and Cuetools asks me to choose the best option from Freedb etc., I choose the closest entry and then manually edit/correct tracknames, genre etc and then click 'OK.' Cuetools used to accept my changes and encode the new files with my changes, but now it seems to ignore any changes I make and simply uses the Freedb entry (or whichever other option I chose) in its original state, ignoring my input.

It's probably something stupid I'm doing but I can't figure it out at all and I can't seem to find anyone with a similar problem. Any help would be greatly appreciated!

Edit: Just saw the previous two posts which I think are alluding to the same problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2011-06-19 14:00:46
Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".

You can do it in a couple of clicks, e.g. by right-clicking on "Local DB"->"by Verification Date"->"Today", etc.

Huh? Nothing happen when I right-click on that green icon. And there's no "Local DB" anywhere else...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-19 14:21:37
Actually you need to right click on the sub-sub-category, not the green icon itself.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-19 15:22:52
Why not something like right click the green "Local DB" icon in the "Folder browser", to "Clear the Local DB".

You can do it in a couple of clicks, e.g. by right-clicking on "Local DB"->"by Verification Date"->"Today", etc.

Huh? Nothing happen when I right-click on that green icon. And there's no "Local DB" anywhere else...

(http://s3.cuetools.net/misc/remove.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-19 18:16:22
Rips with silent tracks are still not reported as accurate in the batchlog
Also rips with all tracks accurate somewhere (on different pressings) but not within the same offset are sorted as accurate in the local database, even if reported as not accurate in the batchlog.


edits aren't saved in tags or locally anymore.

A hot-fix for some of those issues: http://www.cuetools.net/install/CUETools_2.1.2a.rar (http://www.cuetools.net/install/CUETools_2.1.2a.rar)
It's still not a complete fix, for example new metadata fields are still not saved to tags, i'll have to work out some tag mapping scheme for this, probably configurable as in fb2k, but that will have to wait till the next version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2011-06-19 19:00:48
[attachment=6567:cuetools.png]

Where do I click to see that tree? I have looked everywhere I can't find it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-19 19:12:04
You have to switch to Folder Browser mode: (http://s3.cuetools.net/misc/folderbrowser.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2011-06-19 19:15:03
Oh dang, I totally forgot about that mode! Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-20 02:43:59
I just found this in my collection & I wonder if this is normal ??? At first I thought AR V2 was conflicting with AR V1 but it doesn't as when AR V2 seems to disagree all entries are in fact in AR V1, but what I don't really understand is why AR V2 reports "No match but offset" instead of simply "No match" because I thought AR V2 was still using AR V1 to find offset. Maybe it is perfectly normal & my knowledge is partial. (Sorry if the question is dumb, but I don't feel like digging all the thread to find if I missed something... So thks a lot if you can light my lantern!)

Quote
[CUETools log; Date: 18/06/2011 08:52:22; Version: 2.1.2]
[CTDB TOCID: qY2dAI_n3ZMGjPFnnLiRqOBK8cg-] disk not present in database.
[AccurateRip ID: 0038a45c-0365a3e7-21119115] found.
Track  [ CRC    ] Status
01    [0e2ddf38] (3/5) Accurately ripped
02    [14edaa99] (3/5) Accurately ripped
03    [8655448d] (3/5) Accurately ripped
04    [d0c5eaaa] (3/5) Accurately ripped
05    [071cfb94] (3/5) Accurately ripped
06    [cf6b6325] (3/5) Accurately ripped
07    [b4f969a5] (4/4) Accurately ripped
08    [2c45475e] (4/4) Accurately ripped
09    [66ffcf01] (3/5) Accurately ripped
10    [838a43f5] (3/5) Accurately ripped
11    [cc173105] (3/5) Accurately ripped
12    [92c8789b] (3/5) Accurately ripped
13    [6c8f0970] (3/5) Accurately ripped
14    [a84a6937] (3/5) Accurately ripped
15    [5263512e] (3/5) Accurately ripped
16    [9e513207] (3/5) Accurately ripped
17    [6337b5eb] (3/5) Accurately ripped
18    [bef1e9d7] (3/3) Accurately ripped
19    [94f9274f] (3/3) Accurately ripped
20    [9f69423e] (3/3) Accurately ripped
21    [f6720d66] (3/3) Accurately ripped
AccurateRip v2:
01    [ebf2a53a] (2/5) Accurately ripped
02    [4bf8a27a] (2/5) Accurately ripped
03    [58b70fae] (2/5) Accurately ripped
04    [8c3c500d] (2/5) Accurately ripped
05    [87f9de6b] (2/5) Accurately ripped
06    [c373159d] (2/5) Accurately ripped
07    [86ceab88] (0/4) No match but offset
08    [577e6a52] (0/4) No match but offset
09    [1513cd84] (2/5) Accurately ripped
10    [08c49dc7] (2/5) Accurately ripped
11    [09d48d38] (2/5) Accurately ripped
12    [46c46ea2] (2/5) Accurately ripped
13    [6e962e45] (2/5) Accurately ripped
14    [6004ea77] (2/5) Accurately ripped
15    [f531aa1b] (2/5) Accurately ripped
16    [02c82794] (2/5) Accurately ripped
17    [a6c8e4d3] (2/5) Accurately ripped
18    [c99751e2] (0/3) No match but offset
19    [331ece41] (0/3) No match but offset
20    [95d5899a] (0/3) No match but offset
21    [07bbe596] (0/3) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
--  96,6 [0A97FFC0] [52EBC20D]         
01  95,0 [75D86578] [74EFD87D]         
02  96,6 [554E360B] [EB980182]         
03  82,3 [9CE89340] [39799E39]         
04  96,6 [1E845856] [ECD213C8]         
05  96,6 [12C194D7] [08367722]         
06  96,6 [39922703] [0EB9675B]         
07  94,9 [2AF77C45] [678F49A7]         
08  77,2 [FC6CA213] [51A5D20B]         
09  96,6 [B806E427] [70CE5D54]         
10  94,6 [73FC443E] [CCA4B237]         
11  93,1 [48079EA7] [5786374A]         
12  74,9 [43F13B2F] [0E5CFAF5]         
13  74,7 [093D05F7] [FDA46E73]         
14  93,2 [D9770915] [5121B56D]         
15  86,5 [A76EE30E] [5EC1C47C]         
16  93,8 [814591D1] [360EF1FA]         
17  88,8 [2772D010] [840EAAC2]         
18  96,6 [1C9BD08D] [3694EB1F]         
19  96,6 [C12AFF99] [40454BED]         
20  96,6 [18C517BF] [077131F0]         
21  96,6 [2078D354] [0732A98C]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-20 03:25:11
It is confusing to think of ARv1 and ARv2 as separate databases. There are not. In fact, when looking at a database entry, there's no way to determine which CRC was computed using ARv1 and which using ARv2. You can only guess that it's a V2 CRC when it matches your local CRC that you know you computed using V2. And all offset-detection CRCs are computed using ARv1, but this doesn't affect anything. It doesn't matter how offsets are detected.

So the first part of this log compares your V1 CRCs against a database entry. And the second part of this log compares your V2 CRCs against the same database entry. Those comparisons are currently done independently. This log is a mirror image of the log you quoted earlier, where the first part said 'No match but offset' and the second part said 'Accurately ripped'.

Would it be more intuitive if CUETools would have merged those two parts of log into somethings like follows?
Code: [Select]
Track [ CRC ,  CRCv2 ] Status
05 [071cfb94,87f9de6b] (3,2/5) Accurately ripped
06 [cf6b6325,c373159d] (3,2/5) Accurately ripped
07 [b4f969a5,86ceab88] (4,0/4) Accurately ripped
08 [2c45475e,577e6a52] (4,0/4) Accurately ripped


And your previous log from a CD that was submitted only using ARv2 would look like this:
Code: [Select]
01 [d48a93b6,eeae9727] (0,1/1) Accurately ripped
02 [58465981,eddfa49f] (0,1/1) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-20 03:45:18
So the answer is that offset finding is not really tied to AR V1 or AR V2 as database, which they are not. But only loosely tied to AR V1 as the way the offset finding CRC is calculated is closer to the algorythm used in AR V1, right ? Saying that AR V1 is used to find offset is a kind of word abuse, cauz there is two AR V1 CRC  in fact (offset finding+verification).

Concerning your displaying proposal, well I like it as long as all is accurate on both AR V1 & V2 as it would be shorter, but it doesn't seems suited to display when all is not perfect, cauz in these cases, I think you'll need additionnal text to explain clashes.

Edit:
Well it seems you've edited your display so it's a moving target.
I would like it better if all was doubled vertically, even the explanation:

Code: [Select]
Track [ CRCv1-CRCv2 ] Status
05 [071cfb94-87f9de6b] (3+2=5) Accurately ripped/Accurately ripped
06 [cf6b6325-c373159d] (3+2=5) Accurately ripped/Accurately ripped
07 [b4f969a5-86ceab88] (4+0=4) Accurately ripped/No Match
08 [2c45475e-577e6a52] (4+0=4) Accurately ripped/No Match


Edit: /code instead of /quote ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-20 04:02:22
the way the offset finding CRC is calculated is closer to the algorythm used in AR V1, right ? Saying that AR V1 is used to find offset is a kind of word abuse, cauz there is two AR V1 CRC  in fact (offset finding+verification).

Exactly. To be even more precise, CUETools is also able to detect offsets using the ARv1 verification CRCs, but only in case of match (so that's not the way those 'no match but offset' messages appear), and that's not the way AccurateRip was originally designed to work.

Concerning your displaying proposal, well I like it as long as all is accurate on both AR V1 & V2 as it would be shorter, but it doesn't seems suited to display when all is not perfect, cauz in these cases, I think you'll need additional text to explain clashes.

What additional text? In a certain sense, there can be no clashes. When you see something like this:
Code: [Select]
07 [b4f969a5] (4/10) Accurately ripped
ARv2:
07 [86ceab88] (0/10) No match but offset

, you have no way of knowing whether those remaining 6 CRCs in database are ARv1 or ARv2 CRCs.

So this would probably still be more readable:
Code: [Select]
07 [b4f969a5,86ceab88] (4,0/10) Accurately ripped

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-20 04:29:06
I was more thinking of something like this:

Quote
07 [b4f969a5] (4/5) Accurately ripped
ARv2:
07 [86ceab88] (1/5) No match

Quote
07 [b4f969a5,86ceab88] (4,1/5) Accurately ripped

or worst:

Quote
07 [b4f969a5] (4/5) No match
ARv2:
07 [86ceab88] (1/5) Accurately ripped

Quote
07 [b4f969a5,86ceab88] (4,1/5) Houstoon, we've got a problem (Spoon lives in Houstoon)

I admit I never meet such clashes, but I don't want them to go un-noticed if ever it would happen. (I hope not...)

Edit: well this time I used /quote as colors didn't work with /code.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-20 04:33:55
There's no such thing as (4/5) No match. No match means (0/5).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-20 04:37:14
Good point  still a single explanation would have to choice between accurate or not. So keeping both vertically is usefull IMHO. (unless you waste time coding which answer to say for each case). I think you get the idea even if I made misstake in my log. I'm trying to understand what an AR V1 vs AR V2 CRC clash would look like no matter who disagree with the other. As far as I understund using 0/x + No match when there is a clash you do as if all was ok, when the machine is maybe really broken. The clashes go almost invisible, buried in the total sum, no ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-20 04:50:59
I still don't understand what do you mean by clashes. The obvious definition would be that according to ARv1 rip is accurate, and according to ARv2 it is not (or vice versa). But the problem is, it cannot say with any confidence that rip is NOT accurate. This situation normally only means that this track was only ripped with ARv1 software (or vice versa), and that rip is really accurate.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-20 05:24:31
Warning: Anything below is maybe a complete pack of FUD bullshits.    sorry ...

Well my problem is not really to determine if wether this rip would be accurate or not, & who would be wrong or right between AR V1 & AR V2, but rather to know if AR V2 is broken or not. Cauz if an AR V1 "rip accurate" conclusion would disagree with an AR V2 "rip not accurate" conclusion, then we can always conclude that it is because AR V2 is stronger than AR V1 & that it does its job by catching errors that slip through AR V1. But if an AR V2 "rip accurate" conclusion would disagree with with an AR V1 "rip not accurate" conclusion, then AR V2 would maybe be broken. I am trying to understand how such a clash would appear in a CT log, if it would appear at all.

Sorry to be paranoid but if I trust AR V1 to be rock solid, AR V2 is still very new to me.

Quote
This situation normally only means that this track was only ripped with ARv1 software (or vice versa), and that rip is really accurate.


I am not sure that I understand this sentence because you seem to say that it is impossible that a pack of users could have reported a rip as accurate using AR V1 & at the same time another pack of users could have reported the same rip as not accurate using AR V2. Well maybe it is not possible if both AR V1 & AR V2 works as they should, but if AR V2 is broken maybe this is possible. So if ever this would happen (I hope not), I wish it could be displayed obviously. Using 0/x no match it seems it would never be displayed anyway even if AR V2 would be broken. Using a single conclusion for both AR V1 & V2 (like you suggested with the new display) would be saying amen to this fact.

Not that this really matter, maybe this is a non-issue... I just ask to try to clarify my self-made FUD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-06-20 09:19:09
Not that this really matter, maybe this is a non-issue... I just ask to try to clarify my self-made FUD.

AR1 match but no AR2 match probably means that there is no AR2 submission for your pressing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-20 21:24:08
Just tried the CUETools V2.1.2a on rips with silent tracks, the bachtlog seems to report them correctly now, but it seems you still cannot fix offset automatically. I use fix to highest offset only if 100% tracks are AR(2). It would be nice if silents track would pass trougth this filter even if not AR(2).

Looking at my rips with silent tracks I found several [00000000] entries in AR that seems bad (orpheline noise entry for obviously silent tracks) & maybe need to be purged, it's likely a job for Spoon.

Tracks 20, 36 & 96 (Marilyn Manson - 1996 - Antichrist Superstar)

[code][CUETools log; Date: 20/06/2011 21:02:09; Version: 2.1.2a]
[CTDB TOCID: l17oSe_XYF25XW2hxythVk2ZNdk-] found.
        [ CTDBID ] Status
        [1fe01a4b] (1/1) Accurately ripped
[AccurateRip ID: 01c6a4f5-62ab4f93-2c122463] found.
Track  [ CRC    ] Status
 01    [4b23ce19] (096/405) Accurately ripped
 02    [fa92fa55] (094/406) Accurately ripped
 03    [bc5d380d] (096/413) Accurately ripped
 04    [f9998e90] (094/407) Accurately ripped
 05    [3374440d] (094/409) Accurately ripped
 06    [3d968825] (092/406) Accurately ripped
 07    [9ef2184d] (093/403) Accurately ripped
 08    [0da904b2] (093/404) Accurately ripped
 09    [4c72ce63] (091/402) Accurately ripped
 10    [31355e3d] (091/398) Accurately ripped
 11    [affd1d20] (094/402) Accurately ripped
 12    [8b14ba33] (092/400) Accurately ripped
 13    [5a296fb3] (091/396) Accurately ripped
 14    [94e8fc9e] (091/396) Accurately ripped
 15    [037d4910] (087/390) Accurately ripped
 16    [b00f0484] (091/385) Accurately ripped
 17    [409e21ca] (008/030) Accurately ripped
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [39bceae7] (086/349) Accurately ripped
AccurateRip v2:
 01    [035322b9] (013/405) Accurately ripped
 02    [0783effa] (012/406) Accurately ripped
 03    [f93c30e6] (013/413) Accurately ripped
 04    [b35dead3] (013/407) Accurately ripped
 05    [41ac57f1] (013/409) Accurately ripped
 06    [7a329800] (013/406) Accurately ripped
 07    [9bc8e5c1] (013/403) Accurately ripped
 08    [0e32b06d] (013/404) Accurately ripped
 09    [26100459] (013/402) Accurately ripped
 10    [7274c591] (013/398) Accurately ripped
 11    [92c4bfd9] (013/402) Accurately ripped
 12    [4abe424e] (013/400) Accurately ripped
 13    [3a3fd387] (013/396) Accurately ripped
 14    [e1d9b50c] (013/396) Accurately ripped
 15    [c400acc5] (013/390) Accurately ripped
 16    [c7779653] (013/385) Accurately ripped
 17    [4301fb7b] (002/030) Accurately ripped
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [73c31145] (012/349) Accurately ripped
Offsetted by -1992:
 01    [93bee790] (009/405) Accurately ripped
 02    [382a6ade] (010/406) Accurately ripped
 03    [db79d6cf] (010/413) Accurately ripped
 04    [fba7b773] (010/407) Accurately ripped
 05    [8764309a] (010/409) Accurately ripped
 06    [21f865f6] (010/406) Accurately ripped
 07    [ded2e896] (010/403) Accurately ripped
 08    [3e9837fa] (010/404) Accurately ripped
 09    [8c226b77] (010/402) Accurately ripped
 10    [c0e75c5a] (010/398) Accurately ripped
 11    [180c855b] (010/402) Accurately ripped
 12    [5eb53dab] (010/400) Accurately ripped
 13    [5a51ab4c] (010/396) Accurately ripped
 14    [22707ff5] (010/396) Accurately ripped
 15    [730531e6] (010/390) Accurately ripped
 16    [d6b61fad] (010/385) Accurately ripped
 17    [06583633] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [775ef473] (010/349) Accurately ripped
Offsetted by -1345:
 01    [32c0890a] (012/405) Accurately ripped
 02    [255c6072] (012/406) Accurately ripped
 03    [765b3aa2] (012/413) Accurately ripped
 04    [d8e622f2] (012/407) Accurately ripped
 05    [96f1a995] (012/409) Accurately ripped
 06    [f43a2bcf] (012/406) Accurately ripped
 07    [58ba3a5a] (012/403) Accurately ripped
 08    [a530d2e3] (012/404) Accurately ripped
 09    [f4d4c81b] (012/402) Accurately ripped
 10    [04cae13e] (012/398) Accurately ripped
 11    [b92d4c37] (012/402) Accurately ripped
 12    [ad1b2e23] (012/400) Accurately ripped
 13    [c8a4ab62] (012/396) Accurately ripped
 14    [f5e4633b] (012/396) Accurately ripped
 15    [4fc7c95b] (012/390) Accurately ripped
 16    [6885b061] (012/385) Accurately ripped
 17    [2186eff8] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [208c3fe9] (011/349) Accurately ripped
Offsetted by -1328:
 01    [f55ee0a9] (035/405) Accurately ripped
 02    [822374e5] (035/406) Accurately ripped
 03    [7eb5536f] (035/413) Accurately ripped
 04    [b0aff29f] (035/407) Accurately ripped
 05    [c391e6f8] (036/409) Accurately ripped
 06    [48162003] (035/406) Accurately ripped
 07    [940f5e9f] (035/403) Accurately ripped
 08    [d8f326e2] (035/404) Accurately ripped
 09    [27284532] (035/402) Accurately ripped
 10    [1e059214] (035/398) Accurately ripped
 11    [2ab9565f] (035/402) Accurately ripped
 12    [dea566c2] (035/400) Accurately ripped
 13    [19f804af] (035/396) Accurately ripped
 14    [bd9364c2] (035/396) Accurately ripped
 15    [fd699f25] (035/390) Accurately ripped
 16    [cdab79bf] (035/385) Accurately ripped
 17    [9adb8056] (002/030) Accurately ripped
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [2327326f] (030/349) Accurately ripped
Offsetted by -747:
 01    [692f161f] (003/405) Accurately ripped
 02    [4218ab29] (000/406) No match
 03    [c0035400] (000/413) No match
 04    [747baa57] (000/407) No match
 05    [3900408b] (000/409) No match
 06    [d088dc97] (000/406) No match
 07    [4dc24a0d] (000/403) No match
 08    [e002b7ed] (000/404) No match
 09    [2eed2694] (000/402) No match
 10    [88c14c8f] (000/398) No match
 11    [f98cdac7] (000/402) No match
 12    [ba577135] (000/400) No match
 13    [b280f684] (000/396) No match
 14    [b9f028f1] (000/396) No match
 15    [63334577] (000/390) No match
 16    [4d14febd] (000/385) No match
 17    [cf8429c8] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [513a0573] (000/349) No match
Offsetted by -681:
 01    [819f8dfa] (042/405) Accurately ripped
 02    [6df41e52] (044/406) Accurately ripped
 03    [17f41ef9] (044/413) Accurately ripped
 04    [5302b1f5] (043/407) Accurately ripped
 05    [03f671ec] (044/409) Accurately ripped
 06    [d02ae344] (044/406) Accurately ripped
 07    [2797ed48] (044/403) Accurately ripped
 08    [3f8bc1cb] (043/404) Accurately ripped
 09    [c286a974] (043/402) Accurately ripped
 10    [9f1a4382] (043/398) Accurately ripped
 11    [77c36958] (042/402) Accurately ripped
 12    [d802ded1] (043/400) Accurately ripped
 13    [bb808006] (041/396) Accurately ripped
 14    [fe53b4a7] (043/396) Accurately ripped
 15    [b79e2f61] (043/390) Accurately ripped
 16    [23b8519f] (043/385) Accurately ripped
 17    [8b268f50] (003/030) Accurately ripped
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [9deef9a5] (036/349) Accurately ripped
Offsetted by -664:
 01    [9a0bf154] (021/405) Accurately ripped
 02    [6b04050a] (021/406) Accurately ripped
 03    [36388002] (021/413) Accurately ripped
 04    [38f786c4] (021/407) Accurately ripped
 05    [19001e28] (021/409) Accurately ripped
 06    [21cd9f2d] (021/406) Accurately ripped
 07    [ababe751] (021/403) Accurately ripped
 08    [734e15ca] (021/404) Accurately ripped
 09    [733e868d] (021/402) Accurately ripped
 10    [5f487a6d] (021/398) Accurately ripped
 11    [9f1bbb02] (021/402) Accurately ripped
 12    [e0c94f5b] (021/400) Accurately ripped
 13    [e3e4b951] (021/396) Accurately ripped
 14    [68a6faf0] (021/396) Accurately ripped
 15    [f63bfc7b] (021/390) Accurately ripped
 16    [58f546c0] (020/385) Accurately ripped
 17    [9c7b209f] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [f122cac5] (016/349) Accurately ripped
Offsetted by -550:
 01    [17e1180f] (000/405) No match but offset
 02    [e3817643] (002/406) Accurately ripped
 03    [8eb54225] (002/413) Accurately ripped
 04    [ce907a5a] (002/407) Accurately ripped
 05    [f5745ae5] (002/409) Accurately ripped
 06    [591ac776] (002/406) Accurately ripped
 07    [5485942e] (002/403) Accurately ripped
 08    [46ddb278] (002/404) Accurately ripped
 09    [3f01f0ad] (002/402) Accurately ripped
 10    [7cf7992f] (000/398) No match but offset
 11    [b7ab0e17] (002/402) Accurately ripped
 12    [bb19cbb8] (002/400) Accurately ripped
 13    [f088df35] (002/396) Accurately ripped
 14    [f7852014] (002/396) Accurately ripped
 15    [40e59ca5] (002/390) Accurately ripped
 16    [46422b63] (000/385) No match but offset
 17    [ea1a3742] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [f134d2b4] (000/349) No match but offset
Offsetted by 6:
 01    [c495b36a] (000/405) No match
 02    [1edc0270] (000/406) No match
 03    [32cb1d3b] (000/413) No match
 04    [b56d056f] (000/407) No match
 05    [f48c59d3] (000/409) No match
 06    [b99080d4] (000/406) No match
 07    [29c04d7f] (000/403) No match
 08    [5c29d70c] (000/404) No match
 09    [428ff790] (000/402) No match
 10    [c4ff2a83] (000/398) No match
 11    [de41076a] (000/402) No match
 12    [c295310e] (000/400) No match
 13    [d758a425] (000/396) No match
 14    [32c7c114] (000/396) No match
 15    [01577c27] (000/390) No match
 16    [d9e8237d] (002/385) Accurately ripped
 17    [3ec14ac2] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [994dd02f] (000/349) No match
Offsetted by 760:
 01    [8beb03eb] (000/405) No match but offset
 02    [ed446133] (008/406) Accurately ripped
 03    [3260126e] (008/413) Accurately ripped
 04    [c40ec9a6] (008/407) Accurately ripped
 05    [451739ed] (008/409) Accurately ripped
 06    [2bdea9dc] (008/406) Accurately ripped
 07    [fb2801c3] (008/403) Accurately ripped
 08    [9011193a] (008/404) Accurately ripped
 09    [439a7be3] (008/402) Accurately ripped
 10    [39daa826] (008/398) Accurately ripped
 11    [490d6594] (008/402) Accurately ripped
 12    [7978cdc2] (007/400) Accurately ripped
 13    [26c39089] (008/396) Accurately ripped
 14    [f548e9f8] (008/396) Accurately ripped
 15    [4a96d80f] (007/390) Accurately ripped
 16    [4e09c7bd] (000/385) No match but offset
 17    [fbcaa9b6] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [625e921e] (000/349) No match but offset
Offsetted by 872:
 01    [dd639869] (021/405) Accurately ripped
 02    [3f31f6d5] (022/406) Accurately ripped
 03    [b3d7b32b] (021/413) Accurately ripped
 04    [dd915cfe] (021/407) Accurately ripped
 05    [990b68d3] (021/409) Accurately ripped
 06    [a02d3c56] (021/406) Accurately ripped
 07    [cfd60456] (022/403) Accurately ripped
 08    [f4206fca] (021/404) Accurately ripped
 09    [da84947b] (022/402) Accurately ripped
 10    [c3348744] (021/398) Accurately ripped
 11    [011f075e] (020/402) Accurately ripped
 12    [8db0c3ae] (021/400) Accurately ripped
 13    [41a9f043] (021/396) Accurately ripped
 14    [f47f871e] (021/396) Accurately ripped
 15    [6ebdf21a] (021/390) Accurately ripped
 16    [3ddb6353] (019/385) Accurately ripped
 17    [2e0ec70d] (002/030) Accurately ripped
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [7bf9ddc2] (017/349) Accurately ripped
Offsetted by 1427:
 01    [1fbb47f9] (000/405) No match but offset
 02    [0b6f9d2b] (008/406) Accurately ripped
 03    [eb8c0bba] (008/413) Accurately ripped
 04    [353f656f] (008/407) Accurately ripped
 05    [f251f9b0] (008/409) Accurately ripped
 06    [6f73d04e] (007/406) Accurately ripped
 07    [a5c9d2b7] (008/403) Accurately ripped
 08    [51ac714f] (008/404) Accurately ripped
 09    [2531f314] (008/402) Accurately ripped
 10    [951e7c9e] (008/398) Accurately ripped
 11    [5822f128] (008/402) Accurately ripped
 12    [5c492651] (008/400) Accurately ripped
 13    [7771265a] (008/396) Accurately ripped
 14    [48394fe3] (008/396) Accurately ripped
 15    [46828872] (007/390) Accurately ripped
 16    [71345b93] (000/385) No match but offset
 17    [fced92bf] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/000) Silent track
 67    [00000000] (000/000) Silent track
 68    [00000000] (000/000) Silent track
 69    [00000000] (000/000) Silent track
 70    [00000000] (000/000) Silent track
 71    [00000000] (000/000) Silent track
 72    [00000000] (000/000) Silent track
 73    [00000000] (000/000) Silent track
 74    [00000000] (000/000) Silent track
 75    [00000000] (000/000) Silent track
 76    [00000000] (000/000) Silent track
 77    [00000000] (000/000) Silent track
 78    [00000000] (000/000) Silent track
 79    [00000000] (000/000) Silent track
 80    [00000000] (000/000) Silent track
 81    [00000000] (000/000) Silent track
 82    [00000000] (000/000) Silent track
 83    [00000000] (000/000) Silent track
 84    [00000000] (000/000) Silent track
 85    [00000000] (000/000) Silent track
 86    [00000000] (000/000) Silent track
 87    [00000000] (000/000) Silent track
 88    [00000000] (000/000) Silent track
 89    [00000000] (000/000) Silent track
 90    [00000000] (000/000) Silent track
 91    [00000000] (000/000) Silent track
 92    [00000000] (000/000) Silent track
 93    [00000000] (000/000) Silent track
 94    [00000000] (000/000) Silent track
 95    [00000000] (000/000) Silent track
 96    [00000000] (000/001) No match
 97    [00000000] (000/000) Silent track
 98    [00000000] (000/000) Silent track
 99    [bac2a86f] (000/349) No match but offset
Offsetted by 2015:
 01    [f3492269] (000/405) No match but offset
 02    [80c531d3] (002/406) Accurately ripped
 03    [54f027e8] (002/413) Accurately ripped
 04    [edc695ec] (002/407) Accurately ripped
 05    [bb2ee106] (002/409) Accurately ripped
 06    [5930e438] (002/406) Accurately ripped
 07    [828d0f5c] (002/403) Accurately ripped
 08    [5efcf7c3] (002/404) Accurately ripped
 09    [1406df21] (002/402) Accurately ripped
 10    [aa50cc96] (002/398) Accurately ripped
 11    [6e95529e] (002/402) Accurately ripped
 12    [f6bf153e] (002/400) Accurately ripped
 13    [8482d80b] (002/396) Accurately ripped
 14    [fd9126a2] (002/396) Accurately ripped
 15    [5fb4d835] (002/390) Accurately ripped
 16    [6a386099] (000/385) No match but offset
 17    [7ae3f8d2] (000/030) No match
 18    [00000000] (000/000) Silent track
 19    [00000000] (000/000) Silent track
 20    [00000000] (000/001) No match
 21    [00000000] (000/000) Silent track
 22    [00000000] (000/000) Silent track
 23    [00000000] (000/000) Silent track
 24    [00000000] (000/000) Silent track
 25    [00000000] (000/000) Silent track
 26    [00000000] (000/000) Silent track
 27    [00000000] (000/000) Silent track
 28    [00000000] (000/000) Silent track
 29    [00000000] (000/000) Silent track
 30    [00000000] (000/000) Silent track
 31    [00000000] (000/000) Silent track
 32    [00000000] (000/000) Silent track
 33    [00000000] (000/000) Silent track
 34    [00000000] (000/000) Silent track
 35    [00000000] (000/000) Silent track
 36    [00000000] (000/001) No match
 37    [00000000] (000/000) Silent track
 38    [00000000] (000/000) Silent track
 39    [00000000] (000/000) Silent track
 40    [00000000] (000/000) Silent track
 41    [00000000] (000/000) Silent track
 42    [00000000] (000/000) Silent track
 43    [00000000] (000/000) Silent track
 44    [00000000] (000/000) Silent track
 45    [00000000] (000/000) Silent track
 46    [00000000] (000/000) Silent track
 47    [00000000] (000/000) Silent track
 48    [00000000] (000/000) Silent track
 49    [00000000] (000/000) Silent track
 50    [00000000] (000/000) Silent track
 51    [00000000] (000/000) Silent track
 52    [00000000] (000/000) Silent track
 53    [00000000] (000/000) Silent track
 54    [00000000] (000/000) Silent track
 55    [00000000] (000/000) Silent track
 56    [00000000] (000/000) Silent track
 57    [00000000] (000/000) Silent track
 58    [00000000] (000/000) Silent track
 59    [00000000] (000/000) Silent track
 60    [00000000] (000/000) Silent track
 61    [00000000] (000/000) Silent track
 62    [00000000] (000/000) Silent track
 63    [00000000] (000/000) Silent track
 64    [00000000] (000/000) Silent track
 65    [00000000] (000/000) Silent track
 66    [00000000] (000/
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-06-20 21:39:58
If you multiply anything by zero you get zero, so those hash values shouldn't come as a surprise.  I don't think anyone needs to bend over backwards to accommodate a small handful of titles, some of which might not even be red book compliant because they contain tracks that are too short in duration.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: james76smith on 2011-06-22 17:55:47
Thanks for the hotfix that now passes most of the tag edits from the 'Select the best match' window...

A couple of feature requests for the next version:

(1) Would it be possile to add formatting options for the track number tag? Cue tools defaults to TRACKNUMBER/TOTALTRACKS, but I prefer just to have TRACKNUMBER. At the moment I have to use a foobar plugin to automate deletion of TOTALTRACKS, but it would be nice to be able to just tell cuetools how I want the track number tag to be formatted.

(2) Something that has never worked - if I change the genre tag in the 'Select the best match' window, the output path is not updated accordingly. Any chance of addressing this? Artist and album edits work ok....

Anyway, thanks for an amazing tool - keep up the great work!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-06-23 10:11:38
HI

I trying to rebuild a flac encoded album from Vinyl Rip. It has 24bit depth and 192kHz sampling rate.
This is the exact error I get:

Exception: Audio format is invalid.

I get the error even with Accuraterip OFF. Is this error because of the vinyl?
I think for just rebuilding is it ok as decoder and encoder can handle this audio format.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-06-23 20:32:36
CUERipper 2.1.2
Is it supposed to submit rips with errors to CTDB? I am trying to rip a scratched disc. There are read errors. (0/x) AccurateRip matches. Yet it submits to CTDB. I then tried it on another drive. Still have errors. It submitted again. Tried on a different system. Still errors. It submitted again. Compared to previous two submissions and said I might repair with CUETools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-06-23 22:18:55
Forgot to mention the errors.

Secure Mode. Suspicious positions. 30+ Retries.

According to http://www.hydrogenaudio.org/forums/index....st&p=704446 (http://www.hydrogenaudio.org/forums/index.php?showtopic=79882&view=findpost&p=704446)
I thought it shouldn't submit.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: X0R on 2011-06-23 22:53:32
HI

I trying to rebuild a flac encoded album from Vinyl Rip. It has 24bit depth and 192kHz sampling rate.
This is the exact error I get:

Exception: Audio format is invalid.

I get the error even with Accuraterip OFF. Is this error because of the vinyl?
I think for just rebuilding is it ok as decoder and encoder can handle this audio format.


I assume the error is because CueTools is not aware of any Audio CDs in 24bit/192khz
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-24 09:08:10
I trying to rebuild a flac encoded album from Vinyl Rip. It has 24bit depth and 192kHz sampling rate.

CUETools only supports CD audio. Too many of it's features wouldn't work for non-CD audio, even cue sheet format itself is supposed to measure track length in minutes:seconds:frames, which are 1/75th of a second = 44100/75 = 588 samples. In theory, CUE sheet format can be extended to support 48/96/192Khz - luckily, 48000 is divisible by 75, so such CUE sheets will probably have frame sizes of 640/1280/2560 samples. Or it can use 100 frames per second for such audio. I know that fb2k supports such non-standard cue sheets, but i don't think that's very useful in CUE Tools.

Secure Mode. Suspicious positions. 30+ Retries.
I thought it shouldn't submit.

Starting with 2.1.2, CUERipper (or EAC) just sends the number of suspicious positions to the server, and server decides whether it will accept such entry and whether it will accept just a set of CRCs or also a parity file.
So CUERipper should submit, but database should refuse such submissions, at least the parity file. If it doesn't refuse, that means i've set error limit too high, but that can easily be fixed.
Was that a Tommy Shaw album?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-06-24 09:19:36
I trying to rebuild a flac encoded album from Vinyl Rip. It has 24bit depth and 192kHz sampling rate.

CUETools only supports CD audio. Too many of it's features wouldn't work for non-CD audio, even cue sheet format itself is supposed to measure audio in minutes/seconds/frames, which are 1/75th of a second == 44100/75=588 samples. In theory, CUE sheet format can be extended to support 48/96/192Khz - luckily, 48000 is divisible by 75, so such CUE sheets will probably have frame sizes of 640/1280/2560 samples. Or it can use 100 frames per second for such audio. I know that fb2k supports such non-standard cue sheets, but i don't think that's very useful in CUE Tools.


I think it's not impossible, just avoid any AccurateRip interaction. I had quick look at the CUEsheet from the vinyl image, and found nothing nonstandard on it, like it looks HERE:

Code: [Select]
REM GENRE "Psychedelic Rock"
REM DATE 1972
PERFORMER "Pink Floyd"
TITLE "Obscured By Clouds"
FILE "Pink Floyd (1972) – Obscured By Clouds_Side 1.flac" FLAC
  TRACK 01 AUDIO
    TITLE "Obscured By Clouds"
    PERFORMER "Pink Floyd"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "When You're In"
    PERFORMER "Pink Floyd"
    INDEX 01 03:04:00
  TRACK 03 AUDIO
    TITLE "Burning Bridges"
    PERFORMER "Pink Floyd"
    INDEX 01 05:35:00
  TRACK 04 AUDIO
    TITLE "The Gold It's In The..."
    PERFORMER "Pink Floyd"
    INDEX 01 09:04:00
  TRACK 05 AUDIO
    TITLE "Wots... Uh The Deal"
    PERFORMER "Pink Floyd"
    INDEX 01 12:11:00
  TRACK 06 AUDIO
    TITLE "Mudmen"
    PERFORMER "Pink Floyd"
    INDEX 01 17:19:00
FILE "Pink Floyd (1972) – Obscured By Clouds_Side 2.flac" FLAC
  TRACK 07 AUDIO
    TITLE "Childhood's End"
    PERFORMER "Pink Floyd"
    INDEX 01 00:00:00
  TRACK 08 AUDIO
    TITLE "Free Four"
    PERFORMER "Pink Floyd"
    INDEX 01 04:31:00
  TRACK 09 AUDIO
    TITLE "Stay"
    PERFORMER "Pink Floyd"
    INDEX 01 08:47:00
  TRACK 10 AUDIO
    TITLE "Absolutely Curtains"
    PERFORMER "Pink Floyd"
    INDEX 01 12:57:00


I suppose nothing inhibits encoding of such CUEsheet to 1audiofile with transformed CUEsheet as I can see only times in standard time format. Have the encoder references it supports up to 192kHz, 32bit and 5.1 channels
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-06-24 09:29:03
As you can see, in this cue sheet track lengths are measured in seconds. I have no idea is it supposed to just ignore frames, or use 1/75th of a second or 1/100th of a second as a frame. There's no standard for this. By the way, having two files and 10 tracks in a cue sheet is nonstandard too. Which software did you use to produce such weird cue sheet?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-06-24 12:24:13
Was that a Tommy Shaw album?


Yes. So I'll guess you don't need the CTDB TOCID.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xz_kostyan on 2011-06-25 23:31:59
I found than 'Array index is out of range..' error (which occurs with mono) doesn't occur when checkbox 'use Accurate Rip' is unchecked.

Oops, forgot to test this version with mono. Does this happen on every CD or only on a particular one?

It happened on every CD I tested (5-6 CDs).
Thanks a lot, there is no this problem in 2.1.2a. Rebooting to windows for converting doesn't longer needed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-06-26 00:31:02
In an attempt to put some ideas together...

Code: [Select]
Track [ CRC ] Status
01 [0e2ddf38] (3/5) Accurately ripped
02 [14edaa99] (4/4) Accurately ripped
03 [8655448d] (4/10) Accurately ripped

AccurateRip v2:
01 [ebf2a53a] (2/5) Accurately ripped
02 [4bf8a27a] (0/4) No match but offset
03 [58b70fae] (0/10) No match but offset

Some interpretation...
1- For each confidence level in ARv1 there will be an equal number of "no match but offset" submissions in ARv2, and vice verse.
Case:
Track 01 is 100% accurate with 3 ARv1 accurate matches and 2 ARv2 accurate matches, making a total of 5 of 5 accurate matches.

2- No match but offset from more than one CRC/submissions means that at least one of them matches the offset.
Case:
Track 03 has 6 remaining CRCs that are reported as "No match but offset", though that may not mean that 6 match the offset. Odds are that only one CRC matches the offset while the remaining 5 don't match at all. IIRC a "no match but offset" is more likely to indicate a bad rip/CRC than a "no match". The point is that maybe this leads to a not so accurate impression of the results, since at a first glance I'm inclined to interpret it as "the 6 CRCs match the offset".

I noticed another difference while comparing old and new logs. Before "partial matches" which I guess are the same as "no match but offset", were displayed as follows
Code: [Select]
04 [34c2703a] (01/01) Partial match
In contrast to new logs:
Code: [Select]
04 [34c2703a] (00/01) Partial match
What was the reason behind the change? somehow the older display seemed easier for comparing the number of accurate matches vs partial matches.

Ideas:

Based on interpretation 1, maybe it's more intuitive to subtract the number of accurate matches to the other total counterpart (ARv1-ARv2).
Instead of:
Code: [Select]
Track [ CRC ] Status
01 [0e2ddf38] (3/5) Accurately ripped
02 [14edaa99] (4/4) Accurately ripped
03 [8655448d] (4/10) Accurately ripped
AccurateRip v2:
01 [ebf2a53a] (2/5) Accurately ripped
02 [4bf8a27a] (0/4) No match but offset
03 [58b70fae] (0/10) No match but offset
...
Code: [Select]
Track [ CRC ] Status
01 [0e2ddf38] (3/3) Accurately ripped
02 [14edaa99] (4/4) Accurately ripped
03 [8655448d] (4/10) Accurately ripped
AccurateRip v2:
01 [ebf2a53a] (2/2) Accurately ripped
02 [4bf8a27a] (0/0) No Matches (or maybe not found*?)
03 [58b70fae] (0/6) No matches or no matches but offset
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-06-26 01:25:37
As a sidenote to previous posts, for a few discs verification results in the following weird report:
Code: [Select]
[AccurateRip ID: 0058ceb7-098243ce-500e3728] found.
Track   [ CRC    ] Status
01     [dd4625bb] (0/0) No match but offset
02     [99ae1c11] (0/0) No match but offset
03     [752ce267] (0/0) No match but offset
... (the same, ad nauseam)
40     [6cd87975] (0/0) No match but offset


So basically the whole disc is in the AR DB but the whole rip has a 0/0 confidence (a mathematician's nightmare).

This seems a bit misleading, at least in its formulation, because:
1. the disc is reported found in the AR DB but
2. it has obviously no tracks recorded ('/0') and yet
3. the software attempts to match a rip with 'nothing' (hence the 'no match'); still
4. it detects (how?) an offset.
First reaction: "Jeez, what is that, is my disc faked, my rip erroneous, should I trash my drive, is AR offline or what?"

In most cases (see above) the user would readily interpret "No match but offset" as meaning "probable bit errors but still able to detect offsets".
I suppose a better formulation could be found for such cases where AR has "0" results (how come, by the way? still haven't found the definitive answer...)

--

A small bug (?) report: the option "Verify if found" does not submit results to the CTDB as the "Default" verify.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-06-26 02:10:50
I'm pretty certain ARv1 and ARv2 use the same offset hashes.  At least this is what I recall reading from Spoon.

How CT handles all the reporting is another matter.  I have not used it since well before ARv2 support was supported, but in the past the reporting around different pressings wasn't exactly clear, in fact it was sometimes outright misleading.  I have no idea what changes have been made and have not looked at any logs that show ARv2 information until now.  With this in mind, let me take my best shot at what is going on based on the rest of the information given by Marc27.

02 [14edaa99] (4/4) Accurately ripped
AccurateRip v2:
02 [4bf8a27a] (0/4) No match but offset

All submissions for this track were accounted for and done as ARv1 and for only one pressing.  No submissions were made as ARv2.

---------------

01 [0e2ddf38] (3/5) Accurately ripped
AccurateRip v2:
01 [ebf2a53a] (2/5) Accurately ripped

All submissions for this track were accounted for and were split between ARv1 and ARv2 as indicated.

---------------

03 [8655448d] (4/10) Accurately ripped
AccurateRip v2:
03 [58b70fae] (0/10) No match but offset

Only four submissions were accounted for, all were ARv1.  Not enough information was given to determine what constitutes the remaining six submissions.  Marc27, did you provide the entire log are there other submissions given for alternate offsets?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: KingUnique on 2011-06-26 23:21:54
When I try to split a flac image and encode the tracks to mp3 using external encoder(lame.exe) I get the following error:

"....\lame.exe returned error code 1"

does anyone know what error 1 means? and how to fix it. If any other details are needed please let me know.


Thanks in advance
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: KingUnique on 2011-06-26 23:44:34
When I try to split a flac image and encode the tracks to mp3 using external encoder(lame.exe) I get the following error:

"....\lame.exe returned error code 1"

does anyone know what error 1 means? and how to fix it. If any other details are needed please let me know.


Thanks in advance


In case it matters I found out that encoding in a CBR mode (using the same external lame.exe) does not cause the error, so obviously the problem is not in the executable.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: deskmate on 2011-06-27 04:21:15
Thanks for this wonderful tool, Gregory, I use it often.

But I have a small feature request. Would it be possible that the feature "input can be a directory with audio files and no cue sheet" also work in batch mode?

with this batch mode, one can convert file format (e.g. from APE to FLAC), joining individual files (if needed), check accurerip and create the cue file in one single button press, recursively!  wow .. we are getting more "APPLE" like ...

Possible?  Please ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Marc27 on 2011-06-27 08:07:12
I put together the tracks from a log posted by Sauvage78 (track 01 & 02 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=759957)) and a case example posted by Gregory (track 03 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=759963)).
I should have mentioned it...

On a side note, I'm not sure what happens with ARv2 information and alternate offsets. I may take a look at more ARv2 logs once I get my computer back.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-06-27 11:14:48
I suppose I should at least look at a log before giving my $0.02.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-06-28 09:08:18
I have feature request, please preserve existing replaygain information after conversion
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-06-28 11:15:45
I have feature request, please preserve existing replaygain information after conversion

I have the opposite feature request  please don't preserve existing replaygain information after conversion (that is, lossless to lossy conversion). I actually noticed some mp3 converted from flac preserve functional replaygain tags, although not always (and I see no clear pattern).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-06-28 11:30:24
I have feature request, please preserve existing replaygain information after conversion

I have the opposite feature request  please don't preserve existing replaygain information after conversion (that is, lossless to lossy conversion). I actually noticed some mp3 converted from flac preserve functional replaygain tags, although not always (and I see no clear pattern).


That's right for ->loosy, but I talked about lossless->losless where no clipping or normalization is applied
Also CUEtools could scan RG again and apply tags after conversion anykind, thre's freeware externals RG scanners.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-06-28 13:51:42
Also CUEtools could scan RG again and apply tags after conversion anykind, thre's freeware externals RG scanners.

Would be great, and there are different 'kinds' of RG so far (vanilla vs. EBU R128) thus a config option would be welcome.


Another bug report with 2.1.2a - even if it's probably tak-related: when verifying TAK files against AR, results can not be embedded as tags in the file (still it works for other lossless formats). Some limitation of the TAK format I guess, which is also less tightly integrated within CueTools...

Btw, takc.exe also fails when attempting to transcode TAK files to other formats while applying an offset (stops immediately with a message ~ 'does not support search'; as a result the takc process is left idling and has to be killed 'by hand', which is outrageously cruel)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 2011-06-29 21:45:21
Thanks, Gregory!

Seems that "Verify only if found" doesn't take in account present CTDB-entry even if "Use CTDB" checked. I suppose it should.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2011-06-30 08:10:24
I'm still accustoming to the new log, so I know for sure you will wisely spare. 

Is this rip accurate or not?
Code: [Select]
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: gVxhEOQHHEPNFvQ9qjE12ZbNjmU-] found.
        [ CTDBID ] Status
        [085e4f05] (2/2) Accurately ripped
[AccurateRip ID: 000a1243-003624b0-3c0a3c06] found.
Track  [ CRC    ] Status
 01    [d0c6fdd1] (0/2) No match but offset
 02    [5793ed0e] (0/2) No match but offset
 03    [8621b7af] (0/2) No match but offset
 04    [506332c0] (0/2) No match but offset
 05    [b5862057] (0/2) No match but offset
 06    [bd42b7cc] (0/2) No match but offset
AccurateRip v2:
 01    [057f19b3] (2/2) Accurately ripped
 02    [442fd49a] (2/2) Accurately ripped
 03    [14e4a138] (2/2) Accurately ripped
 04    [f0486f43] (2/2) Accurately ripped
 05    [05bcb5a6] (2/2) Accurately ripped
 06    [76cec823] (2/2) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100,0 [2944617A] [5D2AC446]  CRC32 
 01  100,0 [BA67ECCA] [BB1C7900]         
 02  100,0 [B721AA8D] [4E492126]         
 03  100,0 [F7562C3A] [B60E0DED]         
 04  100,0 [24376FAD] [C3AC539F]         
 05  99,5 [C95E7F53] [0D31B664]         
 06  99,2 [9AD39544] [276F7423]         
I guess no. Do you?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-06-30 13:49:11
I'm still accustoming to the new log, so I know for sure you will wisely spare. 

Is this rip accurate or not?

I guess no. Do you?

I see CTDB: (2/2) Accurately ripped; AccurateRip: (2/2) Accurately ripped
(no ARv1 entries and (2/2) ARv2 entries)

But I read [a href=\'index.php?act=findpost&pid=759329\']this[/a] and [a href=\'index.php?act=findpost&pid=759959\']this[/a].

Does it really look that different?

Code: [Select]
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: xxxxxxxxxxxxxxxxxxxxxxxxxxx-] found.
[ CTDBID ] Status
[xxxxxxxx] (2/2) Accurately ripped
[AccurateRip ID: xxxxxxxx-xxxxxxxx-xxxxxxxx] found.
Track [ CRC ] Status
01 [xxxxxxxx] (0/2) No match
02 [xxxxxxxx] (0/2) No match
03 [xxxxxxxx] (0/2) No match
04 [xxxxxxxx] (0/2) No match
05 [xxxxxxxx] (0/2) No match
06 [xxxxxxxx] (0/2) No match
Offsetted by 48:
01 [xxxxxxxx] (2/2) Accurately ripped
02 [xxxxxxxx] (2/2) Accurately ripped
03 [xxxxxxxx] (2/2) Accurately ripped
04 [xxxxxxxx] (2/2) Accurately ripped
05 [xxxxxxxx] (2/2) Accurately ripped
06 [xxxxxxxx] (2/2) Accurately ripped

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-06-30 16:06:48
It looks similar but it is not the same:
- the first rip is AR(2) with AR V2 & offset cannot be "fixed" as it is 0 on both AR V1 & V2.
- the second rip is AR(2) with AR V1 & offset can be "fixed" by 48.

Both are accurate.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: TBeck on 2011-06-30 20:22:03
Another bug report with 2.1.2a - even if it's probably tak-related: when verifying TAK files against AR, results can not be embedded as tags in the file (still it works for other lossless formats). Some limitation of the TAK format I guess, which is also less tightly integrated within CueTools...

I don't know CUEtools, but i think this should be easy to implement. Does it take more than storing the data as APEv2 tags, which is the standard for TAK?

Btw, takc.exe also fails when attempting to transcode TAK files to other formats while applying an offset (stops immediately with a message ~ 'does not support search'; as a result the takc process is left idling and has to be killed 'by hand', which is outrageously cruel)

Unfortunately TAKC currently does not have an option to extract only a part of a compressed file. Sorry... I will put it on my to do list.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2011-07-01 01:34:15
I see CTDB: (2/2) Accurately ripped; AccurateRip: (2/2) Accurately ripped
(no ARv1 entries and (2/2) ARv2 entries)

But I read [a href=\'index.php?act=findpost&pid=759329\']this[/a] and [a href=\'index.php?act=findpost&pid=759959\']this[/a].

Does it really look that different?

Code: [Select]
[CUETools log; Date: 30/06/2011 1:55:32; Version: 2.1.2a]
[CTDB TOCID: xxxxxxxxxxxxxxxxxxxxxxxxxxx-] found.
[ CTDBID ] Status
[xxxxxxxx] (2/2) Accurately ripped
[AccurateRip ID: xxxxxxxx-xxxxxxxx-xxxxxxxx] found.
Track [ CRC ] Status
01 [xxxxxxxx] (0/2) No match
02 [xxxxxxxx] (0/2) No match
03 [xxxxxxxx] (0/2) No match
04 [xxxxxxxx] (0/2) No match
05 [xxxxxxxx] (0/2) No match
06 [xxxxxxxx] (0/2) No match
Offsetted by 48:
01 [xxxxxxxx] (2/2) Accurately ripped
02 [xxxxxxxx] (2/2) Accurately ripped
03 [xxxxxxxx] (2/2) Accurately ripped
04 [xxxxxxxx] (2/2) Accurately ripped
05 [xxxxxxxx] (2/2) Accurately ripped
06 [xxxxxxxx] (2/2) Accurately ripped
As sauvage stated some pages back: 'what I don't really understand is why AR V2 reports "No match but offset" instead of simply "No match"'. That "No match but offset" sounds like a bad rip to me too. 


It looks similar but it is not the same:
- the first rip is AR(2) with AR V2 & offset cannot be "fixed" as it is 0 on both AR V1 & V2.
- the second rip is AR(2) with AR V1 & offset can be "fixed" by 48.

Both are accurate.
If first case is accurate, how should I proceed to make it congruent to AR? I mean, getting an "accurately ripped", ya know. 
Here's the EAC log for that rip.

Code: [Select]
AccurateRip summary
 
Track  1  cannot be verified as accurate (confidence 2)  [D0C6FDD1], AccurateRip returned [057F19B3]
Track  2  cannot be verified as accurate (confidence 2)  [5793ED0E], AccurateRip returned [442FD49A]
Track  3  cannot be verified as accurate (confidence 2)  [8621B7AF], AccurateRip returned [14E4A138]
Track  4  cannot be verified as accurate (confidence 2)  [506332C0], AccurateRip returned [F0486F43]
Track  5  cannot be verified as accurate (confidence 2)  [B5862057], AccurateRip returned [05BCB5A6]
Track  6  cannot be verified as accurate (confidence 2)  [BD42B7CC], AccurateRip returned [76CEC823]
 
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report
Regards!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-07-01 04:29:17
If first case is accurate, how should I proceed to make it congruent to AR? I mean, getting an "accurately ripped", ya know. 
Here's the EAC log for that rip.

Code: [Select]
AccurateRip summary
 
Track  1  cannot be verified as accurate (confidence 2)  [D0C6FDD1], AccurateRip returned [057F19B3]
Track  2  cannot be verified as accurate (confidence 2)  [5793ED0E], AccurateRip returned [442FD49A]
Track  3  cannot be verified as accurate (confidence 2)  [8621B7AF], AccurateRip returned [14E4A138]
Track  4  cannot be verified as accurate (confidence 2)  [506332C0], AccurateRip returned [F0486F43]
Track  5  cannot be verified as accurate (confidence 2)  [B5862057], AccurateRip returned [05BCB5A6]
Track  6  cannot be verified as accurate (confidence 2)  [BD42B7CC], AccurateRip returned [76CEC823]
 
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report
Regards!

 EAC with AR support prior to v1.0 beta 1 only had support for ARv1. To get ARv2 support in EAC you need to upgrade. The current version is v1.0 beta 2 (http://www.exactaudiocopy.de/en/index.php/resources/download/).  CUETools v2.1.2a has ARv2 support and is showing you there are (0) ARv1 entries and (2) ARv2 entries out of (2) entries total. Both entries are a match in ARv2.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2011-07-01 12:23:55
It would be great if the 'Correct filenames'-action would create UTF8-encoded CUEs when necessary. At the moment, it substitutes every non-ANSI character with a ?. Therefore, I'm using the 'Encode'-action without audio output and without using any databases to fix the filenames, as that creates unicode CUEs if needed.
However, that doesn't always work as expected though: I thought, when turning off all checkboxes in the 'Tagging'-settings, it would keep everything besides filenames and structure as it is. But for some CUEs/discs, it just removes some REM or CD-TEXT lines. Sometimes it even adds empty CD-TEXT lines (like PERFORMER "") when there were none before. So I need to check the fixed cue against the original manually everytime I do that.
An option to allow/prevent CUETools from creating such CUEs might be a good idea, I bet there are people who don't want it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-07-02 10:27:14
I think this is a bug :
In Settings->AccurateRip->Verify->Write AccurateRip tags is ON
After successfull verify log file is created but tags not updated though. Tested on Image + CUE with APE2 tags.

1 question:
What exactly does fix offset script with encode. I have verified on rip with shifted offset. As best match was results with +6 offset. If chosing Encode+fix offset, the progress failed. If chosen Encode+normal and manually giving offset +6, the progress succeed and offset was fixed. Then what's 'fix offset' good if it can't find correct offset value and apply for reencode. If the offset is obvious from verify results set.

What about the RG rescan? It's not as hard to do by another tool but I forget often to do that. At least preserve existing tags.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ebaboon on 2011-07-02 23:40:29
To Anakunda:
I think this is a bug :
In Settings->AccurateRip->Verify->Write AccurateRip tags is ON
After successfull verify log file is created but tags not updated though. Tested on Image + CUE with APE2 tags.

It’s Not A Bug, It’s A Feature!
"Verify" also writes AR tags in source file on success, but currently only flac album image (with embedded cue) is supported for this.


To Gregory:
Now CUETools after encode, change multivalue tags (album, genre, artist, title) in comma separate one-value form. Example, i have multivalue genre "Jazz-Funk;Soul" after encode genre is one-value "Jazz-Funk, Soul". Please add options to copy this multivalue tags as is, whitout any change.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2011-07-03 02:37:08
EAC with AR support prior to v1.0 beta 1 only had support for ARv1. To get ARv2 support in EAC you need to upgrade. The current version is v1.0 beta 2 (http://www.exactaudiocopy.de/en/index.php/resources/download/).  CUETools v2.1.2a has ARv2 support and is showing you there are (0) ARv1 entries and (2) ARv2 entries out of (2) entries total. Both entries are a match in ARv2.
Oops!  Sometimes I completely forget about this new feature.
This is my very first rip with ARv2 support. Hope to be spared! 
Thanks for your ready guide, korth!
By the way, here's the new log...
Code: [Select]
Exact Audio Copy V1.0 beta 2 from 29. April 2011

EAC extraction logfile from 2. July 2011, 21:10

Jakszyk, Fripp & Collins / A Scarcity of Miracles

Used drive  : HL-DT-STDVD-ROM GDR-H30N  Adapter: 0  ID: 1

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format              : User Defined Encoder
Selected bitrate                : 128 kBit/s
Quality                        : High
Add ID3 tag                    : No
Command line compressor        : C:\Archivos de programa\Exact Audio Copy [v1.0b1]\Flac\flac.exe
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "TITLE=%albumtitle%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "COMMENT=EAC (Secure Mode)" %source% -o %dest%


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  7:26.67 |        0    |    33516 
        2  |  7:26.67 |  4:47.13 |    33517    |    55054 
        3  | 12:14.05 |  7:47.51 |    55055    |    90130 
        4  | 20:01.56 |  8:37.14 |    90131    |  128919 
        5  | 28:38.70 |  5:59.27 |    128920    |  155871 
        6  | 34:38.22 |  9:02.18 |    155872    |  196539 


Range status and errors

Selected range

    Filename D:\Lossless\Jakszyk, Fripp & Collins - A Scarcity of Miracles\Jakszyk, Fripp & Collins - A Scarcity of Miracles.wav

    Peak level 100.0 %
    Extraction speed 6.2 X
    Range quality 100.0 %
    Copy CRC 2944617A
    Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 2)  [057F19B3]  (AR v2)
Track  2  accurately ripped (confidence 2)  [442FD49A]  (AR v2)
Track  3  accurately ripped (confidence 2)  [14E4A138]  (AR v2)
Track  4  accurately ripped (confidence 2)  [F0486F43]  (AR v2)
Track  5  accurately ripped (confidence 2)  [05BCB5A6]  (AR v2)
Track  6  accurately ripped (confidence 2)  [76CEC823]  (AR v2)
 
All tracks accurately ripped

End of status report

==== Log checksum 4821C1E0A71ED22BCC5575B6E56F7FC9E954073131B8FB700CAECD62A25988AF ====
Just nice!
Regards!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: prefab on 2011-07-06 15:23:06
Gregory, thank you very much for 2.1.2a

Any chance of writing the ACCURATERIP tags to ALAC ? Cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mind_vs_body on 2011-07-08 14:45:21
Hello, I have been using a way old CueTools version, and have just upgraded to the 2.1.2 version, which I am pleasantly surprised at evolution of new features :-)  Also appreciating mirroring the syntax used in foobar.

Is it possible to use CueTools to convert a FLAC image and Cue to tracks with revised Cue, and preserve the custom tags?  I see a setting in Advanced>Tagging "Copy unknown tags" which I thought would do this, but it is only copying standard tags (artist, title, etc).  If it is possible would that also include ReplayGain? I'm guessing no from comments just above...

I know I can always use foobar to split to tracks and preserve the tags, and then batch convert the cues with CUE Tools, but would be great to do in one shot.  If this is already answered somewhere else in the thread please point my weary eyes there :-) Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2011-07-09 15:22:30
Would it be possible to add an option for keeping the timestamps of a file when converting or correcting it?

Also, a question about error messages. Like here in that accurip
Quote
[CTDB TOCID: FodNAscYq_hxDOrxrgrUq6AcLBc-] database access error: Timeout für Vorgang überschritten.

and here from a EAC log (with the CTDB plugin, obviously)
Quote
[CTDB TOCID: rQdoeISrw6aMymKgoVQkFW5VbHk-] found, Submit result: database access error: Die Anfrage wurde abgebrochen: Die Anfrage wurde abgebrochen..

Why is a part of it in German? Is it because my OS locale is German? Both programs are set to English, in EAC even the 'always-english-log'-option is set. Can I do something about it?
And while we're at it, I think the submit results shouldn't be included in a EAC log, just the verify results. But that's just my opinion.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pegasus_ST on 2011-07-11 15:53:47
Hello Gregory!

Most of all lossless releases are converted without any problem. Thank you for a great job!
For one of releases (http://rutracker.org/forum/viewtopic.php?t=38592) CUETools 2.1.2a reporting a problem: Exception: Audio format is invalid.
The flac files can be unpacked with native flac.exe without a problem: flac -d *.flac producing a good wav, which can be also played.
Can you check the unpacking alhorithm (libFLAC is used) - what is wrong with thouse files?

If it is a some header problem - can it be avoided to convert the files?
Should the option "Verify" for libFLAC be disabled?

Thank you
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a3aan on 2011-07-11 16:43:15
The latest CUERipper V2.1.2a doesn't write accurip tags to my flac files. Is this a known issue?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pegasus_ST on 2011-07-11 17:21:00
Hello Gregory!

Most of all lossless releases are converted without any problem. Thank you for a great job!
For one of releases (http://rutracker.org/forum/viewtopic.php?t=38592) CUETools 2.1.2a reporting a problem: Exception: Audio format is invalid.
The flac files can be unpacked with native flac.exe without a problem: flac -d *.flac producing a good wav, which can be also played.
Can you check the unpacking alhorithm (libFLAC is used) - what is wrong with thouse files?

If it is a some header problem - can it be avoided to convert the files?
Should the option "Verify" for libFLAC be disabled?

Thank you


The problem is found.

Source files are recoded to 48kHz. Why FLAC? 

It will be good if program can report something like this:
"The source files are not seems to be a CD audio.
Reason: Sample rate is 48kHz"

The suggestion is based on the WAVTools message
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ManekiNeko on 2011-07-11 19:20:24
Using 2.1.2a, converting individual flac files to 1 file-per-album tta+cue, the tta files have apev2 tags. Shouldn't they be ID3 tags? Are apev2 tags now complient in tta files?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-07-11 20:51:06
"Exception: Error reading CD: NO SENSE STRING FOR ASC=02, ASCQ=00"

According to SCSI docs, this error reported by the drive means "NO SEEK COMPLETE", whatever that means. CUERipper can translate most of SCSI error messages to strings, but this one was forgotten. This will be fixed.
My guess is that this drive had unrecoverable problems reading a certain sector of this CD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: JERECHO on 2011-07-15 03:51:56
I cannot for the life of me figure out how to save a log in cue tools.  What on earth am I doing wrong?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-07-15 14:27:29
I cannot for the life of me figure out how to save a log in cue tools.  What on earth am I doing wrong?

I assume you mean 'verify' log. Make sure 'Write AccurateRip log' is ticked and 'In source folder' if you want the log written to the folder where the files are being verified otherwise it is written to the 'Output:' folder shown under 'CUE Paths'. You can also add '.log' to the 'Name format:' if you wish.

pic link snagged from another post for visual reference only. Settings may differ.
(http:////lh5.ggpht.com/_crwZ8AcDnrE/TC9ptFilsXI/AAAAAAAACFk/A1TEnMeN9O8/CUETools%20Advanced%20Settings.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-07-20 15:50:35
There's some strange behavior when there are several logs in folder.

Example.

Folder content:
Arturo  sandoval  &  WDR  Big  Band - Mambo Nights.cue
Arturo  sandoval  &  WDR  Big  Band - Mambo Nights.log
...
Mambo Nights_English.log

The first log ist in Russian, the second one - its English translation.

I start verify and I don't see any warning or dialog.

Now I rename the 1st log into Mambo Nights.log.
When I start verify now a dialog window appears allowing me to select the preferred log.

Do I make something wrong?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-07-20 16:09:09
If CUETools finds a log file that has exactly the same filename as a cuesheet, it uses it.
If not, it tries to find a log file with matching TOC. If there's no such log file, or there's more than one, it asks a user.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-07-21 08:03:00
Quote
If CUETools finds a log file that has exactly the same filename as a cuesheet, it uses it.


This is what I supposed. Thank you!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: angry_dog on 2011-07-21 19:19:45
Please forgive poor English. CUETools writes:
"AR: database access error" what happened?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-07-21 19:50:40
AccurateRip site seems to be having some trouble. Try again later.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-07-21 19:52:40
http://www.hydrogenaudio.org/forums/index....showtopic=89787 (http://www.hydrogenaudio.org/forums/index.php?showtopic=89787)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2011-07-21 23:07:03
Also, this (http://www.hydrogenaudio.org/forums/index.php?showtopic=89802&st=25&#entry763820):
A small % of people are getting routing issues to the new server [hosting AccurateRip and other Illustrate services] and there are a bunch of people who cannot reach it. It is a top priority correct this issue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-07-24 01:36:14
The recent AR server trouble gave me the idea that it would be nice if rips with "database access error" would be automatically sorted in a "database access error" category within the local DB.

Edit: Just as "disk not present in database" should also be sorted in a "disk not present in database" category, I think I already asked for that one but I recall you so that you can fix both in a row. So far it wasn't very important as "disk not present in database" was what was remaining after you manually sorted all the rest, but with the database having access trouble 50% of time, "database access error" & "disk not present in database" get mixed in what remains after you sorted all the rest manually according to the local DB. It's still not a big issue, but ... I mean CT is supposed to be here to ease my life afterall !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fredgoodman on 2011-07-29 18:32:07
I tried out CUETools.  (On a mac under parallels desktop, by the way;  I don't think I had any issues with running it on a virtual machine with mac formatted hard drives.)

I am using it only to verify files previously ripped with various tools before the days of AR.  The feature of being able to manually enter the first track pregap is superbly useful.

I have several questions and minor complaints: 


1)  It is not clear to me whether I first need to ask CT to make a cue sheet.
2)  Although I have checked somewhere to get verbose log files,  the output from a verification differs from time to time. Sometimes it is just one line, and only one track is reported as having been checked, although the progress report during the verification shows all tracks being checked. 
3)  When I do one operation, the entry in the input box changes from the folder I chose to some file in the folder. 
4)  I am not sure whether you are reporting results to AR.  You should not, I think, because  I am checking files previously ripped possibly by possibly inferior ripping programs and sometimes I just guess the first track pregap.

Thanks for this very nice program.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-07-29 22:48:47
1) No, CT will use splitpoints between your files to create a virtual dummy TOC.
2) ?
3) That's recursive scanning I guess. It seems normal.
4) No, nothing is submitted to AR on verification. IIRC maybe something is submitted to CTDB but only if AR(2) [Not 100% sure here].
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-07-29 23:43:18
2)  Although I have checked somewhere to get verbose log files,  the output from a verification differs from time to time. Sometimes it is just one line, and only one track is reported as having been checked, although the progress report during the verification shows all tracks being checked.

It's probably showing a batch log because you selected a folder. Batch mode is meant to verify lots of files in one go, so it only prints one line per album. You can then find the album in Local DB to see the verbose log, or just make sure you select a cue sheet (or an audio file, if there is none), not the folder.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fredgoodman on 2011-07-29 23:49:06
So I guess the bottom line is that I should ask CT to make a cue sheet, and then choose the cue sheet as input for the verification step. Is that correct?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fredgoodman on 2011-07-29 23:55:55
2)  Although I have checked somewhere to get verbose log files,  the output from a verification differs from time to time. Sometimes it is just one line, and only one track is reported as having been checked, although the progress report during the verification shows all tracks being checked.

It's probably showing a batch log because you selected a folder. Batch mode is meant to verify lots of files in one go, so it only prints one line per album. You can then find the album in Local DB to see the verbose log, or just make sure you select a cue sheet (or an audio file, if there is none), not the folder.



How do I access/view  the local DB?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-07-30 00:17:16
Quote
How do I access/view the local DB?


CUE Paths (Main Window)/Input/Folder Browser (Bottom Left)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2011-08-03 21:20:18
Hi.

I've got a feature request.

When being asked whether to submit CTDB data, there's a small tick box that wants me to remember my choise. Now the problem is that it doesn't remember its state.  Basically I want to be asked everytime without having to untick that option, so if I untick it, the next album I verify I want the dialog box to have this option unticked already, if you know what I mean...

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-08-04 00:17:27
Hi.

I've got a feature request.

When being asked whether to submit CTDB data, there's a small tick box that wants me to remember my choise. Now the problem is that it doesn't remember its state.  Basically I want to be asked everytime without having to untick that option, so if I untick it, the next album I verify I want the dialog box to have this option unticked already, if you know what I mean...



Seconded. It is quite annoying having to uncheck this box every time.

I'm also having a problem with CUETools getting stuck on a pregap. If I test a cue without a pregap then add the pregap line to the cue, CUETools returns results for no pregap. Same thing in reverse. If I test with a pregap then without, the results are still for the pregap. I tried deleting the entry from the local DB and restarting CUETools. I finally deleted the local DB and it forgot the previous pregap.


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: robbo1802 on 2011-08-04 17:26:40
Hello,

Another neeb to Cuetools 2.1.2A.  A few simple questions and a question about a log <groan>.

First, between 2002 and 2005 I ripped about 3500 CDs using EAC, these were then encoded to APEs.  About 1200 of these were verified by ripping them on 2 different types of drives and then comparing the results.  Since late 2005 I have basically been listening to them.  For a couple of reasons, I have recently decided to transcode them to FLAC. Fortunately, I found Cuetools which allows me to do so much more.  Unfortunately I am getting many more "not accurate" results than I had expected.  Some I can explain (a leadout issue on an early drive) but others I can't.

One issue is I am in Australia and most modern music CDs sold here were also (in various combinations) remastered, mastered, rearranged, had tracks changed etc, and pressed often (in the 80s and early90s) from either track or whole disc based digital master tapes (Sony PCM16xx U-Matic).  This often results in accuraterip returning a low confidence for popular titles, 0 confidence for the most less popular tittles, or no database entry at all.

I really don't know much about accuraterip as it was in its infancy when I was ripping. I am currently muddling my way through Cuetools and the resultant log files, I suppose it will all eventually become clear.  Now to the questions:
1. is there a manual for Cuetools?
2. is there a guide to interpreting the logs?
3. is there a good explanation of how the accuraterip database verifies the tracks ( it is track based, isn't it????)
4. with various artists albums there appear to be 2 main types of cue sheet:

Code: [Select]
REM ACCURATERIPID 00304806-0287f028-15121c12
PERFORMER "Various"
TITLE "The Best Of The East Coast Blues And Roots Music Festival (CD 2)"
REM DATE 2000
REM GENRE "Blues"
FILE "Various Artists - The Best Of The East Coast Blues And Roots Music Festival (Disc 2 of 2).flac" WAVE
  TRACK 01 AUDIO
    TITLE "G Love & Special Sauce / Blues Music"
    PERFORMER "Various"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Tony Joe White / The Delta Singer"
    PERFORMER "Various"
    INDEX 01 04:16:59
  TRACK 03 AUDIO
    TITLE "Charlie Musselwhite / The Big Boat"
    PERFORMER "Various"
    INDEX 01 08:51:42

and this

Code: [Select]
REM ACCURATERIPID 002391cc-0180ddea-b910f40e
CATALOG 093624686729
PERFORMER "Various Artists"
TITLE "City of Angels"
REM DATE 1998
REM DISCNUMBER 1
REM TOTALDISCS 1
FILE "Various Artists - City Of Angels Movie Soundtrack.flac" WAVE
  TRACK 01 AUDIO
    TITLE "If God Will Send His Angels"
    PERFORMER "U2"
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    TITLE "Uninvited"
    PERFORMER "Alanis Morissette"
    INDEX 00 04:32:13
    INDEX 01 04:33:60
  TRACK 03 AUDIO
    TITLE "Red House"
    PERFORMER "Jimi Hendrix"
    INDEX 00 09:08:70
    INDEX 01 09:10:45
  TRACK 04 AUDIO
    TITLE "Feelin' Love"
    PERFORMER "Paula Cole"
    INDEX 01 13:01:02
  TRACK 05 AUDIO
    TITLE "Mama, You Got a Daughter"
    PERFORMER "John Lee Hooker"
    INDEX 01 18:38:45
  TRACK 06 AUDIO

Which of these is considered the most "acceptable" (if that has any meaning)?  I noticed that different  databases appear to favour different schemes.


Also, I do not know what to make of this log

Code: [Select]
[CUETools log; Date: 5/08/2011 12:34:44 AM; Version: 2.1.2a]
[CTDB TOCID: 6eSv.MMZM7l_9J3YkT4EeahUW.c-] disk not present in database.
[AccurateRip ID: 00304806-0287f028-15121c12] found.
Track  [ CRC    ] Status
 01    [38357a6a] (0/0) No match but offset
 02    [dd866980] (0/0) No match but offset
 03    [e7b3b15e] (0/0) No match but offset
 04    [90c75012] (0/0) No match but offset
 05    [50ddae6d] (0/0) No match but offset
 06    [01d603a5] (0/0) No match but offset
 07    [b90c18f9] (0/0) No match but offset
 08    [e43da2fe] (0/0) No match but offset
 09    [2bfa9f4a] (0/0) No match but offset
 10    [79be0aa4] (0/0) No match but offset
 11    [d95f2e46] (0/0) No match but offset
 12    [ba182d68] (0/0) No match but offset
 13    [0018ce84] (0/0) No match but offset
 14    [66431538] (0/0) No match but offset
 15    [fb6cc9a7] (0/0) No match but offset
 16    [45dd7b4a] (0/0) No match but offset
 17    [fbda9e6d] (0/0) No match but offset
 18    [b8fcc4de] (0/0) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [5DA62C09] [1D6E8764]         
 01  98.4 [5AA0BC10] [74DD99F5]         
 02  99.9 [7BD092FD] [E5915363]         
 03  100.0 [51B7D756] [8ED611E2]         
 04  100.0 [4E771224] [0716E7D8]         
 05  89.0 [F889D9B9] [5D83586C]         
 06  99.8 [A9E24353] [2BE94567]         
 07  100.0 [B49874A7] [7AD02C4C]         
 08  94.4 [FB69F64C] [C518C405]         
 09  89.0 [0F7F529B] [52A79887]         
 10  100.0 [99AEBEC5] [0DEAC2A1]         
 11  93.9 [5208A259] [4512CAB0]         
 12  97.9 [644A77A5] [41256702]         
 13  78.4 [45E4DD4F] [26EAC24E]         
 14  100.0 [267C0718] [E40121FA]         
 15  100.0 [7CAB10AB] [3863F8DD]         
 16  98.4 [5FD54815] [DDDAA824]         
 17  99.9 [1866FB99] [0ACC4021]         
 18  99.9 [F40C451F] [FD15E293]         

While this disc was being verified the acurraterip symbol was in the status bar with a 0 beside it.

I could understand it if there were some tracks with 0/0 - but all tracks? Am I just being dense?

Thanks,
Bob

BTW. Sorry about the rambling.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: giant walking robot on 2011-08-06 05:43:38
Hi fellas, another newbie here.  I've mostly been lurking but figured I'd speak up because I have similar questions to robbo1802 above.  (If one of you could point me to a Cuetools guide/manual it would be much appreciated.)

I'm using Cuetools to split up large flac files into individual tracks and I don't understand the logs.

For example:

Code: [Select]
[CUETools log; Date: 5/11/2011 6:56:30 PM; Version: 2.1.1]
[AccurateRip ID: 000c9374-00537836-79096b08] found.
Track  [ CRC    ] Status
 01    [054fb569] (0/9) No match
 02    [12b7456a] (0/9) No match
 03    [ef75c86a] (0/9) No match
 04    [354bf4f9] (0/8) No match
 05    [eaeed1cf] (0/9) No match
 06    [6877ed3b] (0/9) No match
 07    [9bd777da] (0/9) No match
 08    [e0b55d58] (0/9) No match
Offsetted by -1855:
 01    [ef4ad646] (2/9) Accurately ripped
 02    [ad689173] (2/9) Accurately ripped
 03    [da3a9fe5] (2/9) Accurately ripped
 04    [506a1091] (0/8) No match but offset
 05    [d3884347] (2/9) Accurately ripped
 06    [fc8126d0] (2/9) Accurately ripped
 07    [6eeb6008] (2/9) Accurately ripped
 08    [56d00b11] (2/9) Accurately ripped
Offsetted by 12:
 01    [64f41ac5] (7/9) Accurately ripped
 02    [4968ed2a] (7/9) Accurately ripped
 03    [2518e7ca] (7/9) Accurately ripped
 04    [d157e819] (0/8) No match but offset
 05    [6a99eb6f] (7/9) Accurately ripped
 06    [df060337] (7/9) Accurately ripped
 07    [f89e8e17] (7/9) Accurately ripped
 08    [3e5e201b] (7/9) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  99.7 [52994A3F] [30AABD7D]         
 01  99.5 [30E9376F] [C7F3061C]         
 02  99.5 [ADFEC796] [E5CE296A]         
 03  99.5 [49B24626] [C5BD0089]         
 04  99.5 [8E01E290] [5274FA92]         
 05  99.7 [7BB60CC9] [D1F48EBC]         
 06  99.5 [4790503A] [B4389095]         
 07  98.9 [6A24A9F1] [77A65087]         
 08  98.4 [4A700127] [53558F7F]         

Does this log mean that the current offset is incorrect, and I should adjust it to 12 (or choose "fix offset")?

Sorry for being such a noob.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-08-06 10:42:56
giant walking robot:
I haven't read robbo1802's post, but in your case, it's either:
- the offset was not fixed while ripping & it's not accurate
OR
- the pressing with your offset is not yet in database & it's maybe accurate.

Anyway "fixing" offset alone will not fix track 04, only repairing with CTDB can maybe do that if errors are detected.
By experience I would say that the rip is suspicious & that case 1 is more & more likely as time goes by.
Furthermore, even if your pressing suddenly appear in the AR database, it can very well happen that track 04 will still be not accurate.
It would mean that pressings with offset 0, -1855, 12 are nearly identical except for the offset.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-08-06 11:15:19
robbo1802:
1 & 2 - As sources of information there is this topic, the HA wiki entry & CT official website. (Sometimes Spoon's own AR forum which also helps for AR development & maintenance, but not on CT or logs). Yes learning about CT, AR & CTDB is painfull, but it worths the pain IMHO.
3 - Yes AR is track based, all information about how it works & why, is buried somewhere in this topic.
4 - CT doesn't really care about the cuesheet style. It cares about the TOC, the only thing that matter is that the splitpoints between tracks are at the same place. If the TOC (with some special info like pregap & extra info like datatrack length) is the same it will have the same ID & check against the same CRCs.

Finally rips with AR(0) are rips for which there was at some point an entry in AR which was withdrawn for some reason. Maybe purged virtual drives results or pending conflicting CRCs waiting for a confirmation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: robbo1802 on 2011-08-06 12:57:15
Hi sauvage78,

Thanks for that help.  I must admit I was hoping for a nice manual, trawling through monster threads is not my favourite pastime.


4 - CT doesn't really care about the cuesheet style. It cares about the TOC, the only thing that matter is that the splitpoints between tracks are at the same place. If the TOC (with some special info like pregap & extra info like datatrack length) is the same it will have the same ID & check against the same CRCs.


I wasn't concerned about the how the different cuesheet styles affect CTDB and AR (and as you have explained, they don't), I was more looking to see if one style was considered better than the other.  I would prefer to have all the 'various artist' cue sheets in a single style.

At the moment I am grinding through the task of transcoding all the apes and embedding the cue sheets in the FLAC files.  I am trying to understand all the various combinations of what CT does in the different directory modes and actions.  I am using batch to convert the files and it appears that in this mode CT will check against the AR DB but NOT the CTDB for verification - I find this a bit puzzling.

When I have finished transcoding I will have to do a study of the results to see how well I did with EAC.  Unfortunately, I think there may be more questions than answers, especially when it comes to compilations (both various artists and single artists) as these can be a patchwork of different tracks.

I will also have a look at further editing and addition to the tags on the files and I am wondering what apps are considered best for this.

Thanks again,
Bob
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-06 14:23:36
1. is there a manual for Cuetools?
2. is there a guide to interpreting the logs?

CUETools wiki is open for everyone to contribute. I'm still hoping somebody will write guides there.

3. is there a good explanation of how the accuraterip database verifies the tracks ( it is track based, isn't it????)

It is track based and it's quite simple. It keeps checksums for tracks ripped by different people, and if your track checksum matches the one in database with high confidence level (confidence level is just the number of times such checksum was submitted), you can hope your rip is correct.

4. with various artists albums there appear to be 2 main types of cue sheet:

It's better of course when track author is stored in PERFORMER tag, because this way you can correctly tag your FLACs and you will be able for example to find all tracks by a certain artist in your collection.
The artist / title notation probably only exists because freedb database couldn't handle track artists any other way.

Also, I do not know what to make of this log
While this disc was being verified the acurraterip symbol was in the status bar with a 0 beside it.

There is no data for this CD in AR database. As sauvage78 pointed out, this CD probably was submitted to AR, but later deleted.

I'm using Cuetools to split up large flac files into individual tracks and I don't understand the logs.
Offsetted by 12:
03    [2518e7ca] (7/9) Accurately ripped
04    [d157e819] (0/8) No match but offset
Does this log mean that the current offset is incorrect, and I should adjust it to 12 (or choose "fix offset")?

I wouldn't adjust offset unless you want to create a bit-perfect copy of this CD on a CD-R.
Even if you are sure that offset is wrong (it could be just a different pressing) offset correction doesn't change the actual sound, so what's the point.
CD manufacturers don't worry about offsets, there are dozens of different versions for any popular CD which differ only in offset, because they were produced on different factories.
If CD manufacturers don't care about it, why should you?

This rip also seems to contain an error on track 4, but that has nothing to do with offsets.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-08-07 02:37:29
Is there any way to use CueTools to encode to Wavpack Hybrid (Lossy+Correction)?

I tried to set up a 'custom' encoder command line (wavpack.exe / -b320 -hx -m -c - %O) but nothing happens: the progress bar is stuck at 0% and the wavpack process has to be killed...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: giant walking robot on 2011-08-07 04:10:49
Thanks for the replies.

I'm using Cuetools to split up large flac files into individual tracks and I don't understand the logs.
Offsetted by 12:
03    [2518e7ca] (7/9) Accurately ripped
04    [d157e819] (0/8) No match but offset
Does this log mean that the current offset is incorrect, and I should adjust it to 12 (or choose "fix offset")?

I wouldn't adjust offset unless you want to create a bit-perfect copy of this CD on a CD-R.
Even if you are sure that offset is wrong (it could be just a different pressing) offset correction doesn't change the actual sound, so what's the point.
CD manufacturers don't worry about offsets, there are dozens of different versions for any popular CD which differ only in offset, because they were produced on different factories.
If CD manufacturers don't care about it, why should you?



Forgive my naivety, but if they're virtually meaningless why does everyone crap their drawers about them?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2011-08-07 05:19:29
Forgive my naivety, but if they're virtually meaningless why does everyone crap their drawers about them?


Ignorance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: robbo1802 on 2011-08-07 06:44:55
Forgive my naivety, but if they're virtually meaningless why does everyone crap their drawers about them?


Ignorance.



This is a specialized forum on the internet, so..... obsessive compulsive disorder springs to mind 

Regards,
Bob
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: robbo1802 on 2011-08-07 07:00:24
1. is there a manual for Cuetools?
2. is there a guide to interpreting the logs?

CUETools wiki is open for everyone to contribute. I'm still hoping somebody will write guides there.


Hello Gregory,


Yes, so do I.  I suspect that I am unaware of many of the capabilities of Cuetools and it will take a while to learn with many discarded FLACs along the way.  A quick scan of this thread seems to show 3 main topics:

1.  general enquiries about how to do things,
2.  suggestions for new features/improvements,
3.  what does this log mean?

Of these the third seems the one that causes the most confusion.  One suggestion might be to create 3 stickies rather than just one big one.

I am still very happy that my searching lead me to CueTools.

Regards,
Bob
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-08-08 08:34:30
I agree, robbo1802. IMVHO Cuetools and its CTDB would deserve a category on its own

Bug report (?): when converting with Cuetools 2.1.2a, the resulting files have their name truncated at dots ('.') if the naming template uses %filename% and the converted file has dots in its name.
edit: The same seems to apply for other tags, for instance %album%.

e.g. Aaron Copland - Symphony No.3 and 4.wav converts to Aaron Copland - Symphony No.flac
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ladjack on 2011-08-10 20:54:44
Hi 

Using CUETools can i split one big FLAC image with cue sheet into tracks without any conversion ? I mean split it into number of wavs and than convert them back into number of flac files...

thnx in adv. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-08-10 21:24:19
Hi 

Using CUETools can i split one big FLAC image with cue sheet into tracks without any conversion ? I mean split it into number of wavs and than convert them back into number of flac files...

thnx in adv. 


FLAC is lossless compression, not a conversion. No wavs are harmed in the process. No audio data is lost.
CUETools does everything on-the-fly so a big flac goes in, little flacs come out. You don't need to decompress the file first.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ladjack on 2011-08-11 07:10:49
FLAC is lossless compression, not a conversion. No wavs are harmed in the process. No audio data is lost.
CUETools does everything on-the-fly so a big flac goes in, little flacs come out. You don't need to decompress the file first.


Yes, but the bitrate changes...obviously it depends on what level of compression i select under the `Encoder to use` drop down.

Anyway, thnx korth 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-08-11 08:43:23
Yes, but the bitrate changes...obviously it depends on what level of compression i select under the `Encoder to use` drop down.

Yes the bitrate changes depending on how much effort the encoder is asked to make.  The end result is still lossless.  Maybe I'm missing your point.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ladjack on 2011-08-11 09:41:06
Yes the bitrate changes depending on how much effort the encoder is asked to make.  The end result is still lossless.  Maybe I'm missing your point.


Ok, i see...so as a result i can get multiple tracks in flac with bitrate greater or smaller than original...
The point was to get those tracks with equal bitrate as in the original flac image.

thnx 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-11 11:20:21
I can't imagine why you might want to have equal bitrate. In lossless compression bitrate doesn't affect the audio quality.
Back to your original question, it's not possible to split FLAC without reencoding, because track boundaries don't match frame boundaries, and FLAC format (to be more precise, FLAC subset format which is designed to be compatible with hardware devices etc) doesn't allow variable frame size. Only the last frame in file can be shorter than other frames, so you can shorten the file by reencoding only it's last frame, but you can't extract e.g. second track by reencoding only the first and the last frame, because first frame cannot be shorter than other frames.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ladjack on 2011-08-11 13:12:45
Gregory S. Chudov, very thank you! It is quite useful information for me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: amberdevo on 2011-08-13 12:36:10
I cannot figure out why the files are not being split with Cue Tools 212a.  I'm using Windows 7.  When I select go, I get no change. Any help would be greatley appreciated.  Worked with XP perfectly
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eyes adrift on 2011-08-13 12:47:46
Hi everyone !

Does anybody know if the "Correct filenames" option is available from the command line ? 
I recently renamed a big part of my library and I would like to "correct the filenames" in batch.   

Thanks in advance
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-20 17:34:21
When I select go, I get no change.

Hmm... AFAIK this only happens if you select a folder with no cue sheets and/or supported audio files in it.
CUETools batch-processes this folder, finds nothing, so has nothing to report.

Does anybody know if the "Correct filenames" option is available from the command line ? 
I recently renamed a big part of my library and I would like to "correct the filenames" in batch. 

It is not (yet) supported from the command line, but you can process the whole folder from the GUI.

BTW, are there any CUETools users in Ottawa?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-08-20 18:37:43
Problem: I can't repair it, there 's no possibility (afaict) to tell cuetools which CTDBID to use  if there's more than 1.

I thought CUETools was displaying a choice in such cases. I'll check if it's broken when i get home.
UPD: works for me: (http://img863.imageshack.us/img863/4135/screen3t.th.jpg) (http://img863.imageshack.us/i/screen3t.jpg/)
Make sure you selected 'Encode' action and 'repair' script. Just in case, i removed the duplicate entry from the database. There was a bug for some time last year which caused some duplicate entries, i thought them harmless and didn't get around to remove them.


Should I have a choice to repair in the example below?

[ CTDBID ] Status
[ef492ed9] (330/332) Differs in 3875 samples @48:39:40-48:39:49
[97d87220] (002/332) Accurately ripped

The repair script stops after verify.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2011-08-20 20:16:00
BTW, are there any CUETools users in Ottawa?

Did you finally have the job offer in Canada, you asked for? 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-20 20:25:11
Not yet, but I'm there anyway
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tremmz on 2011-08-20 20:41:19
Extreme noob here lol

OK after I use cuetools how do I use the resulting .cue file to get the single tracks?   
I use winamp.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-20 20:50:00
Not sure what you mean, but my guess is you would want to enable the option to create .m3u playlists.
I'm not sure if winamp can read .cue files. But you can just add the resulting tracks to playlist manually.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tremmz on 2011-08-20 20:58:19
Thanks

What player can read .cue files?
Does creating .m3u files cause loss of quality? Maybe I need a different player.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-20 21:05:28
.m3u files are playlist files, they don't affect quality in any way. Playlists actually contain only a list of audio files, so that you can easily open the whole album in winamp by clicking on this playlist file, instead of opening tracks one by one.

foobar2000 is a good alternative to winamp, but it doesn't support .cue files too well either, and it's user interface is not designed for casual user.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tremmz on 2011-08-20 21:13:01
If I use the .m3u's then I will see a list of each song in winamp play list then, right? So if I want to hear track3 from several albums I can. Right? Because thats what I want to do is select tracks from several artist to play.


Thanks for your help Gregory, much appreciated. I tried it and all is good.   
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-08-20 23:52:05
OK I'll try another question. I'm still searching to see if this or the previous question was asked before.

I've been seeing results like this one

Code: [Select]
[CTDB TOCID: 0xlC92mqIn7mwnplhFVmHA4rjlY-] found.
        [ CTDBID ] Status
        [b4592682] (88/88) Accurately ripped
[AccurateRip ID: 000b1306-004adc5d-5608ee08] found.
Track  [ CRC    ] Status
 01    [adbce40e] (029/149) Accurately ripped
 02    [e740a0db] (028/148) Accurately ripped
 03    [e79c7318] (028/146) Accurately ripped
 04    [c44295bf] (028/147) Accurately ripped
 05    [ea8c045c] (028/146) Accurately ripped
 06    [0fcba565] (027/146) Accurately ripped
 07    [8c458acd] (027/146) Accurately ripped
 08    [26ab6590] (000/142) No match but offset
Offsetted by 42:
 01    [eb8d5120] (014/149) Accurately ripped
 02    [0413bddb] (014/148) Accurately ripped
 03    [b886ea65] (014/146) Accurately ripped
 04    [49bf759a] (013/147) Accurately ripped
 05    [875de345] (014/146) Accurately ripped
 06    [f919c6b9] (014/146) Accurately ripped
 07    [8686d4c4] (014/146) Accurately ripped
 08    [1c801f94] (000/142) No match but offset
Offsetted by 298:
 01    [3a7b88e9] (002/149) Accurately ripped
 02    [d8c6053f] (002/148) Accurately ripped
 03    [84e5966e] (002/146) Accurately ripped
 04    [55d761d8] (002/147) Accurately ripped
 05    [ea708335] (002/146) Accurately ripped
 06    [7df4b101] (002/146) Accurately ripped
 07    [577a86ca] (002/146) Accurately ripped
 08    [047859ca] (000/142) No match but offset
Offsetted by 507:
 01    [cb8bebe4] (015/149) Accurately ripped
 02    [fd9fa8f4] (014/148) Accurately ripped
 03    [55b07c40] (015/146) Accurately ripped
 04    [3bd51c09] (015/147) Accurately ripped
 05    [8de4601c] (015/146) Accurately ripped
 06    [f93fe548] (015/146) Accurately ripped
 07    [f9bc529e] (014/146) Accurately ripped
 08    [063165a8] (000/142) No match but offset
Offsetted by 811:
 01    [71ec5c0e] (003/149) Accurately ripped
 02    [82299d37] (003/148) Accurately ripped
 03    [ccbfe9c4] (003/146) Accurately ripped
 04    [48f90028] (003/147) Accurately ripped
 05    [825c40e4] (003/146) Accurately ripped
 06    [981bb1a9] (003/146) Accurately ripped
 07    [53fea103] (003/146) Accurately ripped
 08    [e8fd37de] (000/142) No match but offset
Offsetted by 877:
 01    [51feea25] (025/149) Accurately ripped
 02    [7beddb21] (027/148) Accurately ripped
 03    [afa33713] (026/146) Accurately ripped
 04    [197f6ece] (027/147) Accurately ripped
 05    [d57c50fd] (026/146) Accurately ripped
 06    [fcac310b] (025/146) Accurately ripped
 07    [1878fb04] (027/146) Accurately ripped
 08    [a8158472] (000/142) No match but offset
Offsetted by 1154:
 01    [3c7eb595] (003/149) Accurately ripped
 02    [9ad1911e] (003/148) Accurately ripped
 03    [c5233b90] (002/146) Accurately ripped
 04    [25a524eb] (003/147) Accurately ripped
 05    [d4ce2e22] (002/146) Accurately ripped
 06    [74306f83] (003/146) Accurately ripped
 07    [ce99aa36] (003/146) Accurately ripped
 08    [67907443] (000/142) No match but offset
Offsetted by 1243:
 01    [edd298c6] (004/149) Accurately ripped
 02    [192987c3] (004/148) Accurately ripped
 03    [e9bbf0a8] (004/146) Accurately ripped
 04    [a91048e4] (004/147) Accurately ripped
 05    [d08f5b2c] (004/146) Accurately ripped
 06    [a649ed28] (004/146) Accurately ripped
 07    [0041dcca] (004/146) Accurately ripped
 08    [3d095324] (000/142) No match but offset
Offsetted by 1499:
 01    [6bfcf7a5] (002/149) Accurately ripped
 02    [4f442436] (002/148) Accurately ripped
 03    [2c99ac18] (002/146) Accurately ripped
 04    [6bca2f12] (002/147) Accurately ripped
 05    [ea21580d] (002/146) Accurately ripped
 06    [721c9baf] (002/146) Accurately ripped
 07    [e01cef9d] (002/146) Accurately ripped
 08    [fcacb219] (000/142) No match but offset
Offsetted by 1587:
 01    [73748552] (003/149) Accurately ripped
 02    [5d4ae6a4] (003/148) Accurately ripped
 03    [0d3dda88] (003/146) Accurately ripped
 04    [f7c4b097] (003/147) Accurately ripped
 05    [000a2afb] (003/146) Accurately ripped
 06    [68c8e36b] (003/146) Accurately ripped
 07    [66f7af31] (003/146) Accurately ripped
 08    [880d2d77] (000/142) No match but offset
Offsetted by 1823:
 01    [a8bab76f] (010/149) Accurately ripped
 02    [a00733a4] (009/148) Accurately ripped
 03    [e34a7302] (009/146) Accurately ripped
 04    [407c2bf4] (009/147) Accurately ripped
 05    [41b0f5f5] (009/146) Accurately ripped
 06    [99a26722] (009/146) Accurately ripped
 07    [e9397a91] (009/146) Accurately ripped
 08    [9e43d20a] (000/142) No match but offset
where the last track has no matches in AccurateRip yet shows Accurately ripped in the CTDB.
Sometimes even when the CTDB differs by a few samples and the rip can be repaired, after repair the results are similar to above.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-21 01:22:43
Should I have a choice to repair in the example below?
The repair script stops after verify.

You should. I will look into it.

I've been seeing results like this one
where the last track has no matches in AccurateRip yet shows Accurately ripped in the CTDB.
Sometimes even when the CTDB differs by a few samples and the rip can be repaired, after repair the results are similar to above.

AR and CTDB ignore slightly different amount of data at the start/end of the disc. CTDB entry also might have a substantial offset, adding to this blind-spot or reducing it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-08-21 02:06:01
Should I have a choice to repair in the example below?
The repair script stops after verify.

You should. I will look into it.

I have XP64 running right now if that helps.

I've been seeing results like this one
where the last track has no matches in AccurateRip yet shows Accurately ripped in the CTDB.
Sometimes even when the CTDB differs by a few samples and the rip can be repaired, after repair the results are similar to above.

AR and CTDB ignore slightly different amount of data at the start/end of the disc. CTDB entry also might have a substantial offset, adding to this blind-spot or reducing it.

Some of these had an incorrect 'Overread into Lead-In and Lead-Out' setting (switched drives and apparently ticked by mistake) so the error is likely genuine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: robbo1802 on 2011-08-22 14:47:00
Hi,

I have recently used CueTools to convert over 3000 single image and cue ape files to flac while embedding the Cue files into the flac files.  At the time the EAC extraction logs (circa 2002 -2004 vintage) were in the same directory with identical file names and log extensions.  I had the "Write extraction log to "LOG" tag" option under tagging ticked.  Cuetools did not embed the log file - did I miss something?

If I stuffed up or Cuetools cannot do this (and even if it can, I suppose it is a bit late now) is there an application than can easily mass embed these logs?  I  have tried a few different taggers but none of them seem to automate the process.  I have tried tag.exe with the -f option but cannot get it to do this without specifying a specific file name and specific log name (no wildcards).  I was never good at writing batch files either although if one already exists that can do this ...

As I see it, it only needs to do 2 things,

embed logsin flacs where the file names match up within a directory structure with and withoug recursion, and,
write its own log where it lists any flac without a matching log file (mostly typos).

Any help would be appreciated

Regards,
Bob
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eyes adrift on 2011-08-23 21:14:29
Does anybody know if the "Correct filenames" option is available from the command line ? 
I recently renamed a big part of my library and I would like to "correct the filenames" in batch. 

It is not (yet) supported from the command line, but you can process the whole folder from the GUI.

I didn't know that I could proceed a folder recursively from the GUI. I thought the proceeding could only by made folder by folder but I was wrong.
I just tried. It's perfect. 

Thanks a lot ! 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-08-27 23:40:38
Can you help me decipher a CUETools verify log?

I don't understand which CTDBID represent my files.

Specifically, does the first line ([160f07dd] (44/99) Has pregap length 00:00:02) represent my files? And would that mean that my files match up with 44/99 other submitters?

[CUETools log; Date: 8/27/2011 6:32:34 PM; Version: 2.1.2a]
[CTDB TOCID: YZfDYvG.T7.KMiza0h3ci7VCHBU-] found.
        [ CTDBID ] Status
        [160f07dd] (44/99) Has pregap length 00:00:02
        [7db454bb] (55/99) Has pregap length 00:00:32
[AccurateRip ID: 0016cd0d-010201fb-b509510f] found...


I guess I just don't understand what CUETools is trying to tell me.

Many thanks!

EDIT: Does it mean that my files match up properly with 44/99 other database submissions?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-08-28 03:58:34
The database knows two different versions of this CD, one has pregap 00:00:02, other has pregap 00:00:32.
Your rip probably doesn't have a pregap (because this information was lost), so CUETools can't compare it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-08-28 10:49:03
Thank you. Just one more question (I need to know this! HA!): If I see the words "Accurately ripped" on one of the CTDBID status lines, is CUETools telling me that my files/disc matches up with other people's?

In other words, is there something (a MAGIC word or phrase) that I should be looking for to tell if my files/disc are comparable to other people's?

Another example:

Code: [Select]
[CUETools log; Date: 8/28/2011 5:44:09 AM; Version: 2.1.2a]
Pregap length 00:00:01.
[CTDB TOCID: ujvjyuIIqdR61HbcM3huXrxTUi8-] found.
        [ CTDBID ] Status
        [4996818b] (002/224) Has pregap length 00:00:00
        [04b5dfbf] (222/224) CD-Extra data track length 18:37:21, Accurately ripped
...


EDIT: So if I do NOT have a cuesheet or log file, I need to be fiddling with the Extra "Pregap" options in CUETools to verify my files are accurate, right?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-08-28 11:03:58
a1020012:
AFAIU, the data stored in CTDB that can used to repair your rip matches which mean that you actually cannot use CTDB to fix it because it is already perfect/fixed for CTDB. This information is a clue that your rip overall is likely not scratched (as a large part of it is not scratched) but as CTDB cannot store the data to repair 100% of the CD, you shouldn't use this clue to tell if your CD is scratched or not, it only tells you that a part of your CD is not scratched. Only AR can tell you if the whole CD is scratched or not.

Edit:
Yes, you need the pregap length, sometimes it will "work" without but only because a pressing without it also exist in the AR database.

The "magic phrase" you're searching for is "Accurately ripped" for all tracks within the same offset under AccurateRip ID with a confidence 2 or higher. (1 if you physically own the CD & never submitted it, which is unlikely if you don't know the pregap ...)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-08-28 13:14:32
Many, many THANKS, sauvage78! IMHO, someone should write a short (a paragraph or two) tutorial/wiki on how to interpret these results. Unless you know what you're looking for, it can be frustrating trying to interpret the Verify Results Log. =)

EDIT: The tutorial should be called, "How to verify that your files have been accurately ripped using CUETools because you stupidly deleted your EAC log files and/or CUE files when you originally ripped your CDs about five years ago. Dummy."
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: vu4kov on 2011-09-01 09:39:38
I'd like to download the 1.95a version of CUETools(or whichever is the last stable before 2.0). Can anyone help me with that?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: CChiappa on 2011-09-01 18:37:31
I'd like to use CUETools to do some Accuraterip validation of flacs I have on Linux.  I can get the UI to start under Mono, but trying to load any flac files leads to ``Error: Unsupported audio type: /foo/bar/whatever.flac''.  I can see some vague discussion about this maybe working under Linux so I am wondering if I might just be missing some libraries or whatnot.  Has anyone gotten this to work?  I'm using 2.1.2a and the latest mono from Debian unstable, if it matters.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2011-09-01 19:08:54
http://www.cuetools.net/wiki/CUETools (http://www.cuetools.net/wiki/CUETools)

Quote
Supported platforms

CUETools is a .NET application, written in C#. Binaries are available for 32 bit (x86) and 64 bit (x64) Windows versions. .NET Framework 2.0 and Visual C++ 2005 SP1 runtime are required. Users report they have been able to use it under linux, using Mono, but in this scenario only WAV audio is supported, as other codecs are not yet ported to C#.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: CChiappa on 2011-09-01 19:17:08
Thanks.  Some previous posts had implied that later versions might include their own managed codecs which would allow it to work, but I guess that's not the case currently.  I'll commandeer a Windows machine to use it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-09-01 20:02:58
Any news regarding Wavpack Hybrid + Correction support ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-09-02 14:14:33
... and support for Lossy M4A with embedded cuesheet (as 'Mp4 chapters')?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dakeryas on 2011-09-02 20:50:57
Hello,

I have not been reading through all the 62 pages but I didn't find much elsewhere in the forum (searching definitely doesn't help for that case).

I would like to point out to you an "issue" that can appear when you want to create one single image CD & cuesheet with CUETools (I'm using 2.1.2a) from a non compliant cuesheet (with gaps appended to the previous track) and multiple files (EAC rips at least).

As for the audio part, there is nothing to worry about, thankfully!

As regards the cuesheet, you may encounter unexpected things as long as you keep your .log files in the same folders as your extracted files.

To cut a long story short: CUETools seems to assume (at least on my tested rips) that the pre-gap lenghts in the EAC logs are always using hundredth of seconds, and not frames, which may indeed be the case according to your EAC settings.

However, if you have chosen to display time with frames, all your log rips will have pre-gap lenghts in frames already (TOC is always written in frames in logs, no matter what display setting you have chosen, pre-gaps are the only things affected by this in the log apparently) . Since CUETools supposes your pre-gaps are not in frames, it converts those numbers (for instance 0:00:00.73 becames 0:00.55) before applying the gaps to the new cuesheet (the one that goes along the newly created CD image) using the INDEX 00 & INDEX 01 structure.

I noticed this by subtracting the former to the latter: the gap lenght in frames didn't match the log one (in frames already) nor the non compliant cuesheet one (checking using foobar for the previous track length, converting to frames, then subtracting INDEX 00 from the non compliant cuesheet to eventually assess the gap in frames) unless multipying by 4/3 (as if converting from frames to hundredth).

Nevertheless, you will encounter the issue only using the drag 'n drop mode in CUETools with one of your track (or all of them, it doesn't matter) to create the aforementioned CD image & cuesheet, even if there is a .cue in the same folder. If you do open the non compliant cuesheet with CUETools then it will generate the new cuesheet according to it and only to it, without checking the .log for the pre-gaps.

Why would you have to use the drag 'n drop mode with one file of each rip's folder if the non compliant cuesheets give flawless results? For instance if you have decided to switch back to the good old method which consits in archiving with one CD image & cuesheet (foobar prefers it!), but that you keep both your old rips and new ones in a big folder, then searching for "02" in windows gives you the albums your ripped with multiple files and leaves the CD images where they are. If your search all the" .cue"s, you will have to process uselessly your old rips (for instance, again).

That's also EAC "fault" in that it doesn't write anything in the log that could lead CUETools to know whether you have chosen to display time with frames.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-02 22:05:15
Hello,

As regards the cuesheet, you may encounter unexpected things as long as you keep your .log files in the same folders as your extracted files.


AFAIK, CUETools only parses text from the log file to get the 'COPY CRC' results. Pregaps and TOC info in the log are ignored.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dakeryas on 2011-09-03 00:08:09
If you give it a cuesheet, yes, it won't look, but if you drag 'n drop one track (file) then it will build the log according to the log that's in the folder, no matter if there is a cuesheet that bears the same name as the log or not in the same folder, I've checked this for tenth of folders now.

The new cuesheet 's gaps match the old non compliant ones only if that's the thing you've opened  in CUETools, otherwise it will compute the pregaps itselft when fed with one track, and it will do it based on the pre-gaps of the .log (there is the problem if there are in frames or hundredth).

That's still much better than creating a new cuesheet with only INDEX 01 since the error between frames and hundredth is not so huge (3/4, 4/3).

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-03 18:37:15
Sorry Dakeryas,

Tested EAC Tracks rip converted to Image+cue.
I have duplicated your 'adjusted gaps' results in all 3 modes (not just drag'n'drop) by simply removing the cue file from the folder and leaving files+log.
In drag'n'drop mode with files+cue+log in the folder, dragging just the cue or dragging the whole folder results in normal gaps and dragging just one of the files results in the 'adjusted' gaps. I'll defer to the program developer.

One question: If you have the original noncompliant (with gaps) cue file, why would you drag'n'drop one of the audio files instead of that cue file?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dakeryas on 2011-09-04 11:01:04
One question: If you have the original noncompliant (with gaps) cue file, why would you drag'n'drop one of the audio files instead of that cue file?


I did answer myself already  .

Why would you have to use the drag 'n drop mode with one file of each rip's folder if the non compliant cuesheets give flawless results? For instance if you have decided to switch back to the good old method which consits in archiving with one CD image & cuesheet (foobar prefers it!), but that you keep both your old rips and new ones in a big folder, then searching for "02" in Windows gives you the albums your ripped with multiple files and leaves the CD images where they are. If your search all the" .cue"s, you will have to process uselessly your old rips (for instance, again).


Maybe I should search for "02" using an advanced research to search through files (Windows 7 does not offer this by default unless indexing .cues or something) so as to process the non compliant cuesheets only.

I also noticed that deleting temporarily the .cue and leaving the files and the .log indeed lead CUETools to create the .cue assuming that the .log displays gaps in the hundredths. This may be useful for some that didn't bother creating cuesheets when ripping and have somewhat found a use for them (and are to lazy to insert the CD again), but it gives false results if you have ripped in frames.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-09-09 21:35:44
This result is a bit hard to interpret: In the CUETools window, it says
CTDB: could not be verified.


In the log file, it says

[CUETools log; Date: 09.09.2011 22:31:21; Version: 2.1.2a]
[CTDB TOCID: KmukQplLtnXLv0PmXDapTnEmYHM-] found.
        [ CTDBID ] Status
        [230dd736] (21/21) Has pregap length 00:00:32



So ... 21 of 21 or not verified?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-09 21:38:23
Yeah, could not be verified == not found. But a similar CD exists in the database, which has a pregap and a confidence level of 21/21
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-09-10 14:05:24
Could be a bit more informative I think. But ... I just recorded a new personal high: 9861 errors corrected in one disc! (One track, actually.) That's a pretty nice tool

Edit: also, got a case with six tracks of 18 corrected.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-12 18:24:11
I finally came across a CD with a non-silent pregap. I had decided to set Gaps handling to Gaps Appended because I'd rather use a PREGAP command for a silent pregap than have a silent HTOA file. I figured if I ever ran across a disc that actually needed the HTOA I would address it then.
I guess I could set it back to Gaps Appended + HTOA and scan the HTOA file (if written) every time to see if the [W/O NULL] CRC is 00000000. Then if it is I could delete the HTOA and edit the cue file adding a PREGAP command.
I just searched through the posts and found a similar option requested last year. Would be much easier if CUETools could do this for me. Say a checkbox under Gaps Appended + HTOA saying Use Pregap if HTOA is silent.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2011-09-12 21:08:37
Gregory, will you add support for XLD log format?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-12 21:13:17
Probably. I got married and moved from Russia to Canada just three weeks ago, so i am a bit busy at the moment
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2011-09-12 22:01:44
Probably. I got married and moved from Russia to Canada just three weeks ago, so i am a bit busy at the moment


I already suspected you are human. Congrats and best wishes to you and your wife!! If you still have some habits of your homeland celebrating such things takes its time

Please, when you just find some time you may do a little new compile 2.12.b for example with the recent fix for FlacCL, so i have to celebrate something at least.

Cheers!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-09-12 23:01:48
Oh my god  ... I just had the same bad feeling as when I learned that Xiphmont had kids ... that day I deleted all my vorbis files & switched to lossless
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-12 23:23:22
Don't worry, we don't have kids  And we actually have been together for 6 years now, we just weren't able to marry before, because Russia is such a backwards country, and because i have a husband, not a wife
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2011-09-12 23:26:49
Don't worry, we don't have kids  And we actually have been together for 6 years now, we just weren't able to marry before, because Russia is such a backwards country, and because i have a husband, not a wife


Ouch! SORRRY! So congrats to you and your husband  Seldom was wrong with that sentense before... Always good for a surprise this forum
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-12 23:36:29
Thank you
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-09-13 06:46:46
All happy wishes!

* insert giant igloo wedding cake picture, 'blame Canada', and a card with http://xkcd.com/99/ (http://xkcd.com/99/) *
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-13 07:14:12
Oh my  Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2011-09-13 15:48:21
Well, that was slightly unexpected. Congratulations and best wishes to you and your husband! I hope you settle in quickly and enjoy living Canada.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2011-09-18 00:33:52
Please, when you just find some time you may do a little new compile 2.12.b for example with the recent fix for FlacCL, so i have to celebrate something at least.

Cheers!

What for a fix is that, if I may ask? 

Congrats to the newlyweds too... If not for the 100000th disc in the CTDB, that's another valid reason to celebrate
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2011-09-18 01:01:39
What for a fix is that, if I may ask?

Nothing to wurry to much. I stumbled across a file that gave a verify error. It only seems to happen on files with a special kind of its final block and is ultra-rare. Gregory already has the fix in the Repository.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-18 22:03:46
Yes, CONGRATS! Ain't love grand?

I'm about to split all of my single-file FLACs into multi-tracks. They were ripped with EAC many, many moons ago.

As a noobie to CUETools I was just wondering, should I be applying any offset when splitting? Want to keep everything as original to my CDs as possible!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-09-18 23:04:24
No
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-09-19 19:27:14
That's a bug report, sometimes my CUEtools config file gets reset to defaults.
I've created some new profiles today and added several encoder profiles. After restart the cuetools config were set to defaults and new encoder profiles were lolst. Dunno on which conditions this happens. Mostly my config is kept.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-19 20:36:23
I own two copies of the same CD. Why is the first log adding "CD-Extra data track length 18:37:21" to the results line?

Does it mean that CD 1 *should* have the CD-Extra data track, but it doesn't?

Code: [Select]
CD 1:
[CUETools log; Date: 9/19/2011 3:26:14 PM; Version: 2.1.2a]
Pregap length 00:00:01.
[CTDB TOCID: ujvjyuIIqdR61HbcM3huXrxTUi8-] found.
        [ CTDBID ] Status
        [4996818b] (002/224) Has pregap length 00:00:00
        [04b5dfbf] (222/224) [b]CD-Extra data track length 18:37:21, Accurately ripped[/b]
Code: [Select]
CD 2:
[CUETools log; Date: 9/19/2011 3:29:38 PM; Version: 2.1.2a]
Pregap length 00:00:01.
[b]CD-Extra data track length 18:37:21.[/b]
[CTDB TOCID: ujvjyuIIqdR61HbcM3huXrxTUi8-] found.
        [ CTDBID ] Status
        [4996818b] (002/224) Has pregap length 00:00:00
        [04b5dfbf] (222/224) [b]Accurately ripped[/b]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-20 00:06:57
I own two copies of the same CD. Why is the first log adding "CD-Extra data track length 18:37:21" to the results line?

Does it mean that CD 1 *should* have the CD-Extra data track, but it doesn't?

CUETools did not find evidence of a data track for CD 1. By evidence I mean a line in the cue file showing an extra data track or the TOC in the extraction log file showing an extra track. CD 2 has one or both. The audio tracks are showing 'Accurately Ripped' regardless.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-20 00:13:49
That's a bug report, sometimes my CUEtools config file gets reset to defaults.
I've created some new profiles today and added several encoder profiles. After restart the cuetools config were set to defaults and new encoder profiles were lolst. Dunno on which conditions this happens. Mostly my config is kept.

I thought  it was my unstable system when it happened to me. Only happened a couple times in v2.1.1. I keep backups now just in case but haven't needed them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-20 00:16:25
> Does it mean that CD 1 *should* have the CD-Extra data track, but it doesn't?
Basically, yes. It means that CD in database has data track, but yours doesn't. I wouldn't go as far as saying that it *should*
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-20 01:49:15
I own two copies of the same CD. Why is the first log adding "CD-Extra data track length 18:37:21" to the results line?

Does it mean that CD 1 *should* have the CD-Extra data track, but it doesn't?

CUETools did not find evidence of a data track for CD 1. By evidence I mean a line in the cue file showing an extra data track or the TOC in the extraction log file showing an extra track. CD 2 has one or both. The audio tracks are showing 'Accurately Ripped' regardless.

Very helpful info, thank you! My last question on CD-Extra data tracks then, would be this: To repair CD 1 (add the data track) with CUETools, do I simply enter the proper Data Track into the Extra box in CUETools and re-encode?

Keep in mind, I get it that the album is already good to go. Just trying to get 'er as close to original as possible (and almost done learning CUETools! =) ).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-20 03:19:50
I forgot to mention CUETools looks at the DISCID in the cue file.
No need to re-encode. The data track is not ripped but when calculated into the TOC it changes the DISCID and the AccurateRip ID. If you verify with the data track info entered in the box, the AccurateRip results will be for a different AccurateRip ID. The audio tracks do not change.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-20 10:18:57
I get it. Makes perfect sense.

From what I gather, the same also applies to the Pregap. Neither the Pregap nor the Data Track affect the actual audio files, they are just lines in the .cue and/or .log which helps identify a particular Disc. If I'm looking for "bit-perfect" results when burning my files to CD-R, I should have this info.

Again, thank you! Very helpful forum!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2011-09-20 12:52:10
By the way, why is it that in foobar2000, the "File Verifier" component is able to correctly verify an album with AccurateRip, even when the Pregap or Data Track info is missing, and CueTools is not able to do this?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-20 14:11:39
foo_verifier is verifying against results submitted without pregap or data track. If you try to verify where there isn't a record you'll get
Quote
No such disc found in the AccurateRip database.
Please make sure you have selected a complete disc rip with correct track order.
If the disc contains hidden tracks, you can only verify it through a matching cuesheet with hidden track information intact.
for both missing pregap and missing data track info.
I just checked several discs and the accuraterip results were different (when found) when the pregap or data track info was removed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-20 15:26:03
More testing. Cannot edit previous message. I was testing cue file vs tracks instead of editing the cue file.
Actually the DISCID in the cue file seems to be ignored by foo_verifier and get a syntax error when data track included in cue file. Looks like results are always for a disc without a data track. Jumped the gun on the previous post.

example
foo_verifier (using cue file, DISCID includes data track)
Code: [Select]
Track  Status
01    Accurately ripped, confidence: 7.
02    Accurately ripped, confidence: 7.
03    Accurately ripped, confidence: 7.
04    Accurately ripped, confidence: 7.
05    Accurately ripped, confidence: 7.
06    Accurately ripped, confidence: 8.
07    Accurately ripped, confidence: 7.
08    Accurately ripped, confidence: 7.
09    Accurately ripped, confidence: 8.
10    Accurately ripped, confidence: 8.
11    Accurately ripped, confidence: 7.
12    Accurately ripped, confidence: 7.
CUETools (using same cue file, DISCID includes data track)
Code: [Select]
Track   [ CRC    ] Status
 01    [e2b1cbab] (095/107) Accurately ripped
 02    [c74f8c0f] (096/108) Accurately ripped
 03    [30742b55] (097/108) Accurately ripped
 04    [c36bcd74] (097/109) Accurately ripped
 05    [a8525823] (096/107) Accurately ripped
 06    [74f1b33f] (097/108) Accurately ripped
 07    [4cd6bbdd] (095/106) Accurately ripped
 08    [0273e25a] (094/105) Accurately ripped
 09    [4bf380c6] (094/106) Accurately ripped
 10    [69f77194] (095/107) Accurately ripped
 11    [a9edd59c] (094/106) Accurately ripped
 12    [e2ddc88e] (095/107) Accurately ripped
AccurateRip v2:
 01    [0b7fc922] (006/107) Accurately ripped
 02    [32ee4cd2] (006/108) Accurately ripped
 03    [a8f5820c] (005/108) Accurately ripped
 04    [25dc0d4e] (006/109) Accurately ripped
 05    [ae19fdcb] (005/107) Accurately ripped
 06    [f5cf0306] (005/108) Accurately ripped
 07    [13293e2c] (005/106) Accurately ripped
 08    [4bf07b48] (006/105) Accurately ripped
 09    [aa2f352e] (006/106) Accurately ripped
 10    [3cc3b0c7] (006/107) Accurately ripped
 11    [fef6160e] (006/106) Accurately ripped
 12    [794fe5df] (006/107) Accurately ripped
Offsetted by -646:
 01    [700314b4] (006/107) Accurately ripped
 02    [403c0a7a] (006/108) Accurately ripped
 03    [a30e8c9e] (006/108) Accurately ripped
 04    [7eca1d58] (006/109) Accurately ripped
 05    [5745968f] (006/107) Accurately ripped
 06    [877732bb] (006/108) Accurately ripped
 07    [ed0626a3] (006/106) Accurately ripped
 08    [2f32b28a] (005/105) Accurately ripped
 09    [ef5e582d] (006/106) Accurately ripped
 10    [6e7301ad] (006/107) Accurately ripped
 11    [e47058b1] (006/106) Accurately ripped
 12    [d3ca62a5] (006/107) Accurately ripped
CUETools (no DISCID in cue file, no data track info)
Code: [Select]
 01     [e2b1cbab] (07/09) Accurately ripped
 02    [c74f8c0f] (07/09) Accurately ripped
 03    [30742b55] (07/09) Accurately ripped
 04    [c36bcd74] (07/09) Accurately ripped
 05    [a8525823] (07/09) Accurately ripped
 06    [74f1b33f] (08/10) Accurately ripped
 07    [4cd6bbdd] (07/09) Accurately ripped
 08    [0273e25a] (07/09) Accurately ripped
 09    [4bf380c6] (08/10) Accurately ripped
 10    [69f77194] (08/10) Accurately ripped
 11    [a9edd59c] (07/09) Accurately ripped
 12    [e2ddc88e] (07/09) Accurately ripped
AccurateRip v2:
 01    [0b7fc922] (02/09) Accurately ripped
 02    [32ee4cd2] (02/09) Accurately ripped
 03    [a8f5820c] (02/09) Accurately ripped
 04    [25dc0d4e] (02/09) Accurately ripped
 05    [ae19fdcb] (02/09) Accurately ripped
 06    [f5cf0306] (02/10) Accurately ripped
 07    [13293e2c] (02/09) Accurately ripped
 08    [4bf07b48] (02/09) Accurately ripped
 09    [aa2f352e] (02/10) Accurately ripped
 10    [3cc3b0c7] (02/10) Accurately ripped
 11    [fef6160e] (02/09) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-20 16:23:35
Two easy Q's about offsets, then I think I'm good to go with CUETools (love this app!).

1. Approximately how many seconds (milliseconds) are there for one offset? e.g. +6 offset = X milliseconds. Or, stated differently, how many write offsets would equal one second of audio? Just looking for a guesstimate, not an exact calculation.

2. When selecting "fix offset", does CUETools GUESS which offset is correct (assuming there are multiple offsets that would make all tracks Accurate) or does it use info from the .cue (DISCID?) and/or .log?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-09-20 16:33:40
1: As far as I remember 1 is 1/75 of a second.
2: By default CT fix to closest, there is a radio button to fix to highest. (It doesn't guess.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-09-20 16:38:12
1. Approximately how many seconds (milliseconds) are there for one offset? e.g. +6 offset = X milliseconds. Or, stated differently, how many write offsets would equal one second of audio? Just looking for a guesstimate, not an exact calculation.

6/44100 ? 0.136 ms or 136 ?s (136 microseconds or millionths of a second)

One second of audio equals 44100 samples.

1: As far as I remember 1 is 1/75 of a second.

One second of also audio equals 75 frames, where one frame equals 588 samples, but offsets are measured in samples, not frames.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-20 17:19:45
I now see the option for "to nearest" under AccurateRip options. Still not clear how CT makes it's judgement of what is nearest. I would think the DISCID in the .cue would help.

So correcting an offset of 6 to audio tracks is practically like doing "nothing" to them at all. Or even adjusting 500.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-09-20 17:24:07
Is it possible that you simply have a pressing not in the database, in which case correcting the offset will match a disc belonging to someone else, rather than the original that was ripped?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-09-20 17:49:21
Still not clear how CT makes it's judgement of what is nearest.

6 is nearer than 18. 18 is nearer than 30. 30 is nearer than -48.

I would think the DISCID in the .cue would help.

The DISCID "aabbbbcc" is aa=checksum, bbbb=total seconds, cc=# of tracks, all in hex. Not much help.

So correcting an offset of 6 to audio tracks is practically like doing "nothing" to them at all. Or even adjusting 500.

Provided there are enough null samples. Applying an offset greater than the null samples available will result in data loss. A live recording, for example, could be damaged. (I'm referring to a manual adjustment, not the 'fix offset' feature.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-09-20 17:57:52
If I were right, an offset of say +/-2000 would means a few seconds, so I now realized I answered too quickly. Greynol is right, it's very very small.

Edit:
Personnaly I fix to highest only if all tracks are AR(2) since  a couple of years now (since the feature was added in fact) I never heard anything wrong (I do this to have the highest display first in log).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-20 18:03:55
Is it possible that you simply have a pressing not in the database, in which case correcting the offset will match a disc belonging to someone else, rather than the original that was ripped?

Yes, exactly -- and that's why I need to understand what I'm doing before I alter my tracks. Understanding how CT makes it's decision to "fix offset" is the info I'm after. If it is 100% certain that it's choosing the right offset, I'll do it. If CT is just guessing, I won't.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-09-20 18:12:46
What is the proper offset correction for the drive used (relative to the EAC reference adopted by AccurateRip), and was it applied at the time of the rip?

CT does not have any provision to ensure that the criteria I provided in the question above is met.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-09-20 18:27:09
Something like the "correct" offset is dream as the CD makers themselves don't care about offsets.
As an end user what matters is that you at least match a pressing within the offset range of the AR ID so that your log is shorter & doesn't display "No match" on all tracks for "offset 0".
So, the "fix offset" feature doesn't really "fix" audio, it mainly fixes cosmetics within the log.
It is not a feature for people who always fix their drive offset correctly while ripping. It's mainly for people who discover the existence of offsets with AR & CT.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-09-20 18:33:57
As an end user what matters is that you at least match a pressing within the offset range of the AR ID so that your log is shorter & doesn't display "No match" on all tracks for "offset 0".

Speak for yourself!

This concern about offsets and what is shown in log files is really nothing more than anal-retentiveness.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-09-20 18:36:46
I just learned a new word: retentiveness, thks, I already knew the other one ! lol

... and yes offet are a#?*, I never said I care about offsets ... I don't even know their length !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2011-09-20 19:29:19
http://en.wikipedia.org/wiki/Anal_retentive (http://en.wikipedia.org/wiki/Anal_retentive)
http://www.urbandictionary.com/define.php?...nal%20retentive (http://www.urbandictionary.com/define.php?term=anal%20retentive)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a1020012 on 2011-09-21 22:19:35
Just curious, why does CT sometimes popup asking me which log to pick when there is only one in the directory?

Also, does this still apply?
(from CT Wiki (http://cuetools.net/wiki/CUETools) under "What's wrong if i'm sure the CD is present in the database, but CUETools doesn't find it")
Quote
"For this to work, .log file should have the same filename as a .cue file, except for extension."
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-21 23:15:44
When .log file has the same filename as a .cue file, it silently used.
If not, it can be also silently used if it's the only .log file with matching TOC in the directory.

Log files from old EAC versions don't contain TOC, and EAC by default uses different filenames for .cue and .log files, so CUETools has to ask user for confirmation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2011-09-23 16:54:23
Congratulations on having the EAC plugin included in the install package. The EAC effect is clearly visible: http://db.cuetools.net/stats.php (http://db.cuetools.net/stats.php) , can't wait for the next EAC release, I'm sure it will be default.

I hope you will continue to develop CTDB, many more things can be accomplished.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-23 18:02:06
Thanks! Support of the HA community is what made it possible.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2011-09-26 18:16:25
Is there a changelog for the CTDB plugin? What's new in V2.1.3?
EDIT: Okay I just realized the options slightly differ, as you can set the metadata search mode now. Though I'm not really sure what it is about at this moment.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-26 18:49:27
2.1.2 supported only Musicbrainz, 2.1.3 supports also Discogs and Freedb. Full search in all databases can take quite a lot of time, and produce too many results, so the default mode looks for exact match in Musicbrainz, then tries Discogs and Freedb, if still out of luck - tries fuzzy search. Fast mode doesn't do fuzzy searches, and Exhaustive mode does every kind of search and returns all results. This logic is inside the CTDB server and can change over time, if i find better ways to do it. I recommend keeping the default setting.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2011-09-26 19:04:29
Okay, thank you for the quick response. I just realized you can select the CTDB plugin as metadata provider in EAC, so that's what it's for.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spies on 2011-09-29 16:09:49
Does CUERipper have any command line options for running from the console? If not this is my request to add some.  I know CUETools has a couple as listed on the wiki but I was not able to find any listed for CUERipper.  My goal is to try and use CUERipper with a CD changer for automated ripping and having CUERipper controllable from the console would make this task a whole lot easier. Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-09-29 16:43:22
Code: [Select]
C:\Users\user\Downloads\CUETools_2.1.2a>CUETools.ConsoleRipper.exe -h
CUERipper v2.1.2 Copyright (C) 2008-10 Gregory S. Chudov
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Usage    : CUERipper.exe <options>

-S, --secure             secure mode, read each block twice (default);
-B, --burst              burst (1 pass) mode;
-P, --paranoid           maximum level of error correction;
-D, --drive <letter>     use a specific CD drive, e.g. E: F:;
-O, --offset <samples>   use specific drive read offset;
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spies on 2011-09-29 17:07:13
Thank you Gregory!  How on earth did I miss that?  Off to try my lame scripting skills.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spies on 2011-10-01 23:09:03
I managed to get CUETools.ConsoleRipper.exe working with my Sony VGP-XL1B2 using a very crude batch file!  However it turns out CUETools.ConsoleRipper.exe does not seem to be entirely compatible with the MATSHITA DVD-RAM SW-9584 mechanism that is in the changer.  I am guessing it has something to do with the over read capabilities of the drive?  The result is that the first track ripped from the disc does not match the database and while ripping the last track CUETools.ConsoleRipper.exe reports 15 ripping errors at the very end of the disc however it does match the database along with all of the other tracks on the disc.  Its the same for every disc I have tried so far.  All these discs rip without errors and match the database with my LITE-ON  DVDRW SOHW-1693S.  Any suggestions making this work outside of replacing the changer? Thanks!

A little more detail as it turns out using CUETools.ConsoleRipper.exe in secure mode on this drive results in errors across the whole disc as opposed to just the end when in burst mode.  I am also curious if CUETools.ConsoleRipper.exe has the ability to submit to the CUETools DB.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2011-10-04 09:58:15
Hi,

Can you please explain to me this result:

Quote
.\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 1)\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 1).cue: AR: rip accurate (36/55), CTDB: verified OK, confidence 36.
.\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 2)\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 2).cue: AR: rip accurate (36/57), CTDB: verified OK, confidence 1.
.\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 3)\Talking Heads - 2003-11-18 - Once in a Lifetime (disc 3).cue: AR: rip accurate (34/56), CTDB: verified OK, confidence 34, or differs in 8920 samples, confidence 1.


How come the second disk only has confidence 1, and the other two have confidence 34/36?
It seems that the disk two and three has the confidence from the AR database and was submitted to the database by CUETools, but the second disk was ripped with CUERipper or EAC. Why doesn't the second disk has the same confidence as the as AR confidence (36)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-10-05 19:43:45
Why doesn't the second disk has the same confidence as the as AR confidence (36)?

Likely because the first submission came from a rip. Once a CTDB record is created, the confidence only increases with each additional rip. If someone had made the first submission using CUETools verify, the confidence would have been set to match the current AR confidence.
Perhaps the user who submitted the other two discs had an inaccurate copy of disc 2.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2011-10-05 23:42:19
Maybe, once a rip has been made, the confidence level should include only the submitted rips, and only a disk without a rip, submitted by CUETools, should have the AR confidence level.

A confidence level beyond 2 or 3 becomes irrelevant for checking the accuracy of a rip. But I like statistics, and the confidence level tells you how popular a disk is, unfortunately this is not possible right now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-10-06 19:53:21
However it turns out CUETools.ConsoleRipper.exe does not seem to be entirely compatible with the MATSHITA DVD-RAM SW-9584 mechanism that is in the changer.

This seems to be a rare drive, there's only one submission in the database that uses this drive (unsuccessful rip of Genesis - Abacab), and i assume it's yours. Does EAC work ok with this drive?

I am also curious if CUETools.ConsoleRipper.exe has the ability to submit to the CUETools DB.

No, it doesn't. It was basically a test project for CUERipper development. It could be turned into a fully functioning CD ripper by adding a few features, if there is a demand for this, but this is not a priority right now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-10-06 20:08:53
It seems that the disk two and three has the confidence from the AR database and was submitted to the database by CUETools, but the second disk was ripped with CUERipper or EAC. Why doesn't the second disk has the same confidence as the as AR confidence (36)?

Maybe, once a rip has been made, the confidence level should include only the submitted rips, and only a disk without a rip, submitted by CUETools, should have the AR confidence level.

A confidence level beyond 2 or 3 becomes irrelevant for checking the accuracy of a rip. But I like statistics, and the confidence level tells you how popular a disk is, unfortunately this is not possible right now.

When the database was created, we had only AccurateRip confidence levels to go on. There was also hope of a closer integration with AccurateRip, which would allow the database to update confidence numbers directly from AR.

By the time EAC plugin was created, it have become clear that there will be no integration with AccurateRip, so new submissions from EAC don't use AR confidence levels.

In the near future, i plan to reset CTDB confidence levels to the actual number of independent submissions.

You'll have AccurateRip confidence scores in your ripping log anyway, so what's the point to duplicate them in CTDB section.

The only drawback is that when repairing a rip, you'll have to re-verify it after repair to find out AccurateRip confidence levels for the repair result. But this can be fixed. I will probably have to make CUETools show the "future" AccurateRip verification log when selecting an entry to use for repair. Does this make sense?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2011-10-07 01:13:22
Thanks. I will have to re-generate the logs for my entire collection, so I can feed updated data in my charts and pies generating scripts  can't wait for the reset.

I think that the cases when a rip is repaired are so rare that a re-check isn't that big of a deal.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spies on 2011-10-07 06:46:44
This seems to be a rare drive, there's only one submission in the database that uses this drive (unsuccessful rip of Genesis - Abacab), and i assume it's yours. Does EAC work ok with this drive?
Yep that was probably mine, sorry.  The drive works great with EAC as well as dBpoweramp.  With EAC it works best if I leave over read disabled.  With dBpoweramp it works best leaving C2 disabled as well.  EAC works just fine with C2 enabled with this drive however.  Are there any logs I can provide to get to the bottom of this? I really appreciate your help!
No, it doesn't. It was basically a test project for CUERipper development. It could be turned into a fully functioning CD ripper by adding a few features, if there is a demand for this, but this is not a priority right now.
Even with its limited features it pretty much does exactly what I want if only it would work properly with my drive.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: koawmfot on 2011-10-07 14:58:44
hi gregory... i've been using cuetools for a few versions now and i love the product and the constistent improvements. 

i have been wanting to use the cue ripper and responded to this thread about problems i was having and am hoping you can help.

http://www.hydrogenaudio.org/forums/index....c=82797&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=82797&hl=)

Quote
i have the same error with plextor drives W2410A, fw 1.03 and W1210A fw 1.10. the error occurs on windows XP and windows 7 x64, and three different physical computer systems. cueripper freezes when you hit "go" and it starts "detecting drive features..." it will take about 5-10 minutes, the give the error "Error Reading CD IoctlFailed". after that the drive is dead in windows and i have to reboot to get it back.

i have an internal laptop drive that is ok (HL-DT-ST DVD+RW GSA-T21N A1R1) and which can rip a CD, so i know the application works. when i try the same system with the plextors, it does not work.

any ideas?


the drives are both ide, and i have tried them through USB enclosures as well.  i do have a SCSI version of the 1210 but i have not brought it home yet.

what do you think?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-10-07 17:30:53
It's sad. Unfortunately, support for old drives is not my priority. I don't have that drive, and even if i could get one, by the time i'm done with it i would probably be one the last people on earth who use it  I'm much more concerned with support for new drives, which EAC often has problems with. Of course i'd like CUERipper to at least fail gracefully when encountering unsupported drives, so i'll try to look into it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: s_PLASH on 2011-10-07 22:07:59
hallo dear developer
(http://s14.directupload.net/images/111007/temp/fel4njqb.jpg) (http://s14.directupload.net/file/d/2670/fel4njqb_jpg.htm)(http://s14.directupload.net/images/111007/temp/qf59f4cc.jpg) (http://s14.directupload.net/file/d/2670/qf59f4cc_jpg.htm)
what you see is a difference in appearance when you change display 100% to 125% in win 7. you cant see or access offset settings (right on the bottom of the window). also you notice a strange border on the left side, which i can live with, but also would be happier without it. would you PLESE fix it in your next release?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-10-07 22:19:20
I'll try
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: s_PLASH on 2011-10-07 23:03:06
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: koawmfot on 2011-10-08 20:10:10
It's sad. Unfortunately, support for old drives is not my priority. I don't have that drive, and even if i could get one, by the time i'm done with it i would probably be one the last people on earth who use it  I'm much more concerned with support for new drives, which EAC often has problems with. Of course i'd like CUERipper to at least fail gracefully when encountering unsupported drives, so i'll try to look into it.


i am pretty sure i have an extra ide of the 1210a... i'd be happy to send it to you without any need to return it.  they're pretty reliable and it'd be great if your app could work with them.  i had thought quite a few people still used these for their reliability and full feature set (accurate stream, c2 errors, HTOA, and overread into both).  i use the plextor-specific switch " -usefua" with eac to disable the write cache.

anything i could try in the meantime and maybe debug info i could send your way?  maybe the console ripper?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: koawmfot on 2011-10-10 00:22:32
i couldn't edit my above post.

here is the log output of the console ripper:

Code: [Select]
C:\Users\user\Desktop\CUETools_2.1.1\CUETools.ConsoleRipper.exe -D d: -O +99 -P --be

CUERipper v2.1.2 Copyright (C) 2008-10 Gregory S. Chudov
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Drive       : d: [PLEXTOR  CD-R   PX-W1210A 1.10]
Read offset : 99
Read cmd    : BEh, 12h, , 16 blocks at a time
Secure mode : 2
Filename    : Jimi Hendrix - Kiss the Sky.wav
Disk length : 46:42:40
AccurateRip : ok
MusicBrainz : Jimi Hendrix - Kiss the Sky

Error: Error reading CD: IoctlFailed
   at CUETools.Ripper.SCSI.CDDriveReader.FetchSectors(Int32 sector, Int32 Sector
s2Read, Boolean abort)
   at CUETools.Ripper.SCSI.CDDriveReader.PrefetchSector(Int32 iSector)
   at CUETools.Ripper.SCSI.CDDriveReader.Read(AudioBuffer buff, Int32 maxLength)

   at CUETools.ConsoleRipper.Program.Main(String[] args)
[/size]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-10-10 00:35:18
Thank you for your offer. I guess i should take it, because there's not much that can be done without having an actual drive to run tests on.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-10-17 03:38:17
At some point in the development adding a CTDB entry in the folder browser that would automatically sort "By CTDB Status":

- CTDB: Differs (maybe fixable)
- CTDB: Could not be verified (likely not fixable)
- CTDB: Not present in database (unknown)
- CTDB: Verified OK

would be interesting IMHO. CTDB is slowly becoming big enough to justify it.

As a side note, I don't have any grief anymore against the horizontal displaying in log for AR V2. I have tested AR V2 enough now to think that it didn't change anything noticeable for an end user at all. I wasn't too hot to adopt this instanly but my FUD is gone now & the longer logs are just annoying me now as, visually, I often mix them up with rips without fixed offset.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-10-17 03:43:16
Agree.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: A_Man_Eating_Duck on 2011-10-17 05:20:50
Is there a possibility of changing the numbering format that the (HTOA) files are numbered?

The Cue looks like this..
Code: [Select]
REM ACCURATERIPID 00144f96-00d7aee7-b509520e
REM DISCID B509520E
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Green Day"
TITLE "Dookie"
CATALOG 0075994552927
REM DATE 1994
REM DISCNUMBER 1
REM TOTALDISCS 1
FILE "01.00. (HTOA).flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Green Day"
    TITLE "Burnout"
    INDEX 00 00:00:00
FILE "01. Burnout.flac" WAVE
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PERFORMER "Green Day"
    TITLE "Having a Blast"
    INDEX 00 02:07:37
FILE "02. Having a Blast.flac" WAVE
    INDEX 01 00:00:00
  TRACK 03 AUDIO
    PERFORMER "Green Day"
    TITLE "Chump"
    INDEX 00 02:44:46
FILE "03. Chump.flac" WAVE
    INDEX 01 00:00:00
  TRACK 04 AUDIO
    PERFORMER "Green Day"
    TITLE "Longview"
    INDEX 00 02:54:00
FILE "04. Longview.flac" WAVE
    INDEX 01 00:00:00
  TRACK 05 AUDIO
    PERFORMER "Green Day"
    TITLE "Welcome to Paradise"
    INDEX 00 03:59:04
FILE "05. Welcome to Paradise.flac" WAVE
    INDEX 01 00:00:00
  TRACK 06 AUDIO
    PERFORMER "Green Day"
    TITLE "Pulling Teeth"
    INDEX 00 03:44:46
FILE "06. Pulling Teeth.flac" WAVE
    INDEX 01 00:00:00
  TRACK 07 AUDIO
    PERFORMER "Green Day"
    TITLE "Basket Case"
    INDEX 00 02:30:59
FILE "07. Basket Case.flac" WAVE
    INDEX 01 00:00:00
  TRACK 08 AUDIO
    PERFORMER "Green Day"
    TITLE "She"
    INDEX 00 03:01:00
FILE "08. She.flac" WAVE
    INDEX 01 00:00:00
  TRACK 09 AUDIO
    PERFORMER "Green Day"
    TITLE "Sassafras Roots"
    INDEX 00 02:14:18
FILE "09. Sassafras Roots.flac" WAVE
    INDEX 01 00:00:00
  TRACK 10 AUDIO
    PERFORMER "Green Day"
    TITLE "When I Come Around"
    INDEX 00 02:37:44
FILE "10. When I Come Around.flac" WAVE
    INDEX 01 00:00:00
  TRACK 11 AUDIO
    PERFORMER "Green Day"
    TITLE "Coming Clean"
    INDEX 00 02:58:11
FILE "11. Coming Clean.flac" WAVE
    INDEX 01 00:00:00
  TRACK 12 AUDIO
    PERFORMER "Green Day"
    TITLE "Emenius Sleepus"
    INDEX 00 01:34:64
FILE "12. Emenius Sleepus.flac" WAVE
    INDEX 01 00:00:00
  TRACK 13 AUDIO
    PERFORMER "Green Day"
    TITLE "In the End"
    INDEX 00 01:43:71
FILE "13. In the End.flac" WAVE
    INDEX 01 00:00:00
  TRACK 14 AUDIO
    PERFORMER "Green Day"
    TITLE "F.O.D. / All by Myself"
    INDEX 00 01:46:28
FILE "14. F.O.D. _ All by Myself.flac" WAVE
    INDEX 01 00:00:00
Since i rip my files in track mode the (HTOA) files show up in explorer out of order.
e.g.
(http://i.imgur.com/EVogp.png) (http://imgur.com/EVogp)

Would it be possible to have these (HTOA) tracks show up as 00 instead of 01.00?

Also another request, would it be possible to have a button added that would allow all the metadata to automatically change its capitalisation? much like how the feature in EAC.
(http://i.imgur.com/0XKCO.png) (http://imgur.com/0XKCO)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-10-17 05:39:55
I will add it to my list
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: A_Man_Eating_Duck on 2011-10-17 05:58:43
Thank you kind sir
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-10-26 13:37:45
I have a decent bug report,

1. CUEttols doesnot popup the album info dialog before 1st conversion conversion if invoked by CUEtools <dirname>. On 2nd and further conversions the dialog shows correctly.

2. Could it have a better support for album info import, ie. manual Query for muscibrainz and Discogs, plus tracklist import and parsing from clipboard /or/ file

3. I still didnot get how "Fix offset" script really works. I guess that it should adapt the offset out of AccurateRip report with highest matches, but it don't so. Here's an example of AccuRip report:

Code: [Select]
Track   [ CRC    ] Status
01     [e274b577] (015/122) Accurately ripped
02     [5da97f6a] (014/121) Accurately ripped
03     [041db81b] (014/123) Accurately ripped
04     [00e56701] (014/122) Accurately ripped
05     [3f437ebd] (014/122) Accurately ripped
06     [894e8496] (014/120) Accurately ripped
07     [49bce785] (014/120) Accurately ripped
08     [3946afa4] (014/123) Accurately ripped
09     [1df65554] (014/120) Accurately ripped
10     [0820057c] (014/121) Accurately ripped
11     [cfca8f8f] (014/122) Accurately ripped
12     [03bf1bf3] (014/119) Accurately ripped
Offsetted by 664:
01     [10b8d6ef] (056/122) Accurately ripped
02     [6c0a3d7a] (056/121) Accurately ripped
03     [2b3eaa13] (056/123) Accurately ripped
04     [c61ae5e9] (057/122) Accurately ripped
05     [e933e195] (057/122) Accurately ripped
06     [1450505e] (055/120) Accurately ripped
07     [42063585] (055/120) Accurately ripped
08     [cdabef54] (056/123) Accurately ripped
09     [bf35f214] (055/120) Accurately ripped
10     [a295d98c] (056/121) Accurately ripped
11     [0443f077] (057/122) Accurately ripped
12     [6373387b] (055/119) Accurately ripped
Offsetted by 1387:
01     [a6f45f9e] (016/122) Accurately ripped
02     [dc14bc3c] (016/121) Accurately ripped
03     [e60b04d2] (016/123) Accurately ripped
04     [b3f83b46] (016/122) Accurately ripped
05     [88690c70] (016/122) Accurately ripped
06     [a6465157] (016/120) Accurately ripped
07     [caf97f45] (016/120) Accurately ripped
08     [98e4344a] (016/123) Accurately ripped
09     [8ec979ac] (016/120) Accurately ripped
10     [63d49b0e] (016/121) Accurately ripped
11     [61a4a214] (016/122) Accurately ripped
12     [dc3841e7] (015/119) Accurately ripped
Offsetted by 1492:
01     [a5673e5b] (019/122) Accurately ripped
02     [e0aaf922] (019/121) Accurately ripped
03     [8d631ebf] (019/123) Accurately ripped
04     [ddf3326d] (019/122) Accurately ripped
05     [684b9771] (019/122) Accurately ripped
06     [5bdee412] (019/120) Accurately ripped
07     [11d9e885] (019/120) Accurately ripped
08     [2a305c0c] (019/123) Accurately ripped
09     [08491ff4] (019/120) Accurately ripped
10     [f29dfc34] (019/121) Accurately ripped
11     [836301fb] (019/122) Accurately ripped
12     [b492e7eb] (019/119) Accurately ripped
Offsetted by 1522:
01     [12aca291] (008/122) Accurately ripped
02     [98d5e5f6] (008/121) Accurately ripped
03     [2aea0195] (010/123) Accurately ripped
04     [e9f1c22f] (008/122) Accurately ripped
05     [a8432cdf] (008/122) Accurately ripped
06     [d8e5e96c] (008/120) Accurately ripped
07     [93d0e205] (008/120) Accurately ripped
08     [9cd86768] (010/123) Accurately ripped
09     [4f922ae4] (008/120) Accurately ripped
10     [d2453c88] (008/121) Accurately ripped
11     [6874d43d] (008/122) Accurately ripped
12     [ce74a9a3] (008/119) Accurately ripped


Here the offset 664 has the highest match but CueTools didnot use it. The album was converted with existing offset. Could anyone explain?

3. And finally, is there available a complete list of all supported metadata fields and their mappings to media files tags,  that can use in Template field?

I'd Appreciate more foobar metadata and functions supported! Thank U !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-10-26 13:49:55
3- CT will only "fix" offset to highest if you tick (Edit: Untick) the right radio button in the option, by default it "fix" to nearest, but as you rip is already found with the actual offset I am not sure it will fix anything.

Edit: In Settings/AccurateRip/Untick "to nearest" if you want to fix to Highest.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2011-10-26 14:57:13
Here the offset 664 has the highest match but CueTools didnot use it. The album was converted with existing offset. Could anyone explain?


I guess (not sure though) that 'fix' is only supposed to fix something when there are no matches with the current offset. But in your example, there is no need to fix anything, as the current offset matches already.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2011-10-26 17:38:07
Here the offset 664 has the highest match but CueTools didnot use it. The album was converted with existing offset. Could anyone explain?


I guess (not sure though) that 'fix' is only supposed to fix something when there are no matches with the current offset. But in your example, there is no need to fix anything, as the current offset matches already.


Ah so, then is there a way to modify the script the way of my idea ie. adapting the offes with highest match reagdrless if the current offset has or not some matches?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-10-26 18:43:59
The answer is two posts above (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=1600&p=773350&#entry773350). (With a Typo in it: you rip=your rip).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sts78 on 2011-10-28 13:43:03
Until now I used CUEtools just to verify against AR (only verify mode). All fine so far.

But recently I tried to split a big flac into tracks, and went into a problem.
I have a source directory with my flac, the cue and the eac log for input.
I chose the cue for input, "encode and verify", "lossless" and so on, and a output directory (different from input dir).

But when I click on go I instantly get an exception, that the access to the directory is denied    (Windows 7 x64).
Directories have been freshly created with the current user, folder permissions are alright (I think), I even tried to run CUEtools as administrator: no success.

Did I miss a configuration step? Anything else?


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-10-28 15:00:04
A misbehavior report:
With a damaged but CTDB fixable rip that have an extra data file but don't have a log (so no length info):

If CT automatically finds the data track length & you try to repair it, after the reparing the rip is AR not found as it seems the data track length is not automatically applied after the reparing.

Exemple:
Damaged:
Code: [Select]
[CUETools log; Date: 28/10/11 12:33:19; Version: 2.1.2a]
CD-Extra data track length 32:53:50.
[CTDB TOCID: NSFKOWYhdRg5JvTHPsSbYUIVH6I-] found.
        [ CTDBID ] Status
        [205e81aa] (1/1) Differs in 12 samples @04:35:57
[AccurateRip ID: 000f1d51-007811a9-7f11af0a] found.
Track   [ CRC    ] Status
01     [251c8174] (2/2) Accurately ripped
02     [de2afa36] (0/2) No match but offset
03     [aaddb5c4] (2/2) Accurately ripped
04     [80eefc16] (2/2) Accurately ripped
05     [14ea8187] (2/2) Accurately ripped
06     [a78830c5] (2/2) Accurately ripped
07     [b96f1704] (2/2) Accurately ripped
08     [538cf213] (2/2) Accurately ripped
09     [987b6e4b] (2/2) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   98,7 [31E95D45] [439F38B1]          
01   59,7 [E28F0A65] [35FF4800]          
02   98,7 [11C967E5] [49FA5025]          
03   98,7 [56420A86] [0841F570]          
04   98,7 [396F04C5] [BA7238A5]          
05   98,7 [250AC844] [3EAFDFD3]          
06   98,7 [405E456A] [D89DABCC]          
07   98,7 [828BB200] [4C6E261F]          
08   98,7 [9976F05A] [F8FA4991]          
09   98,7 [4CECDF52] [36B60187]


After reparing:
Code: [Select]
[CUETools log; Date: 28/10/11 15:42:10; Version: 2.1.2a]
CD-Extra data track length 32:53:50.
CUETools DB: corrected 12 errors.
[AccurateRip ID: 000f1d51-007811a9-7f11af0a] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
--   98,7 [437B0988] [82B5FA4C]          
01   59,7 [E28F0A65] [35FF4800]          
02   98,7 [342F4426] [D9F55817]          
03   98,7 [56420A86] [0841F570]          
04   98,7 [396F04C5] [BA7238A5]          
05   98,7 [250AC844] [3EAFDFD3]          
06   98,7 [405E456A] [D89DABCC]          
07   98,7 [828BB200] [4C6E261F]          
08   98,7 [9976F05A] [F8FA4991]          
09   98,7 [4CECDF52] [36B60187]


Should have been: (Manual re-verification of the same fixed data as above)

Code: [Select]
[CUETools log; Date: 28/10/11 15:43:50; Version: 2.1.2a]
CD-Extra data track length 32:53:50.
[CTDB TOCID: NSFKOWYhdRg5JvTHPsSbYUIVH6I-] found.
        [ CTDBID ] Status
        [205e81aa] (1/1) Accurately ripped
[AccurateRip ID: 000f1d51-007811a9-7f11af0a] found.
Track   [ CRC    ] Status
01     [251c8174] (2/2) Accurately ripped
02     [9c754a56] (2/2) Accurately ripped
03     [aaddb5c4] (2/2) Accurately ripped
04     [80eefc16] (2/2) Accurately ripped
05     [14ea8187] (2/2) Accurately ripped
06     [a78830c5] (2/2) Accurately ripped
07     [b96f1704] (2/2) Accurately ripped
08     [538cf213] (2/2) Accurately ripped
09     [987b6e4b] (2/2) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   98,7 [437B0988] [82B5FA4C]          
01   59,7 [E28F0A65] [35FF4800]          
02   98,7 [342F4426] [D9F55817]          
03   98,7 [56420A86] [0841F570]          
04   98,7 [396F04C5] [BA7238A5]          
05   98,7 [250AC844] [3EAFDFD3]          
06   98,7 [405E456A] [D89DABCC]          
07   98,7 [828BB200] [4C6E261F]          
08   98,7 [9976F05A] [F8FA4991]          
09   98,7 [4CECDF52] [36B60187]


Not that it matters much if you are aware of it, but it is missleading as I could have thought that my rip wasn't fixed if I would not have manually re-verified.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-10-28 15:53:01
I chose the cue for input, "encode and verify", "lossless" and so on, and a output directory (different from input dir).

Sounds like an older version.

But when I click on go I instantly get an exception, that the access to the directory is denied    (Windows 7 x64).

I'm still using XP but I know Windows 7 has very strict access rights inside the "Program Files" directories. If you are running CUETools from there, you might try running from something like C:\CUETools instead.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sts78 on 2011-10-28 16:06:14
Don't remember the exact version (currently not sitting in front of the concerning machine), but the current installation is from a build I downloaded just two to three weeks ago from the official site.
Well, I mistyped the set options I made (tried it from memory). It's actually "encode", "tracks", "losless"...
I installed it outside the program files directory, actually on another drive.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-05 16:55:41
I need some advice. Perhaps this question relates more to AccurateRip than CUETools, but here goes...

I verified a Frank Zappa CD this morning with CUETools 2.12a that came up with the following verification results:

C:\...\Hot Rats flac.cue: AR: rip accurate (231/260), CTDB: verified OK, confidence 209, or differs in 170 samples, confidence 1.

I am inclined to think this is a good rip, matching 231 samples of 260 using the AccurateRip database. However, the CTDB "differs in 170 samples" has me thinking my CD rip may have defects.

Is this a good rip of "Hot Rats"?

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-05 17:22:16
I am inclined to think this is a good rip, matching 231 samples of 260 using the AccurateRip database
Not samples, database entries.

However, the CTDB "differs in 170 samples" has me thinking my CD rip may have defects.
Is this a good rip of "Hot Rats"?
Yes
CTDB: says
verified OK, confidence 209
or
differs in 170 samples, confidence 1

You match 209/210, that's good.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-05 18:09:25
You match 209/210, that's good.


Thanks for educating me, Korth!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-07 19:07:15
Hello, all.

I have a .CUE and an associated .APE image for an album and need to convert them into separate tracks. What is the best way to this with the most recent version of CUETools and still retain the correct offsets and AccurateRIP data that CUETools says are proper? I do know there is one HTOA.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2011-11-07 20:22:25
@Gregory

In post #1321 I had some trouble with fixing a bad rip because CTDB had 2 entries and I didn't get the pop-up  for choosing which one CT should use. In post #1525 Korth has the same problem.
You mentioned you would look into it. Any news on that?

P.S. I'm using also win7 64bit.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-07 23:22:02
I have a .CUE and an associated .APE image for an album and need to convert them into separate tracks. What is the best way to this with the most recent version of CUETools and still retain the correct offsets and AccurateRIP data that CUETools says are proper? I do know there is one HTOA.

Advanced Settings-CUETools-Gaps Handling: Gaps Appended + HTOA
Input mode shouldn't matter. I use Multiselect Browser and select the cue file.
(main window)
Action: Encode (default)
Mode: Tracks
Audio Output: Lossless (you can convert or keep APE)
Extra:
Pregap: 00:00:00
Data Track: 00:00:00
Offset: 0
Verify your output to check for changes. Unless this disc is an exception, there shouldn't be any.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-08 01:36:11
I have a .CUE and an associated .APE image for an album and need to convert them into separate tracks. What is the best way to this with the most recent version of CUETools and still retain the correct offsets and AccurateRIP data that CUETools says are proper? I do know there is one HTOA.

Advanced Settings-CUETools-Gaps Handling: Gaps Appended + HTOA
Input mode shouldn't matter. I use Multiselect Browser and select the cue file.
(main window)
Action: Encode (default)
Mode: Tracks
Audio Output: Lossless (you can convert or keep APE)
Extra:
Pregap: 00:00:00
Data Track: 00:00:00
Offset: 0
Verify your output to check for changes. Unless this disc is an exception, there shouldn't be any.


Thanks, korth. I figured this all out tonight... The pregaps were giving me problems matching AccurateRip but once I added those back into to my makeshift .CUEs, everything is matching up and working well.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-11-10 03:46:12
You mentioned you would look into it. Any news on that?

Unfortunately, i was not able to reproduce it... Works for me using the same disc.
(http://s016.radikal.ru/i335/1111/59/e5ed346796b7.png)
If this happens again, please provide more details - a copy of your settings etc.

I'm currently working on an update to CTDB. One of the things i wanted to address is the readability of the log.
How about replacing this:
Code: [Select]
        [ CTDBID ] Status
        [fbead10c] (05/10) Differs in 104 samples @00:00:21
        [93e09601] (02/10) Accurately ripped
        [0697adde] (02/10) No match
        [f101c3d3] (01/10) No match

with this:
Code: [Select]
 Track  | CTDB Status
   1   | ( 2/10) Accurately ripped, or (5/10) differs in 104 samples @00:00:21
   2   | ( 9/10) Accurately ripped
   3   | (10/10) Accurately ripped
   4   | (10/10) Accurately ripped
   5   | (10/10) Accurately ripped
   6   | ( 8/10) Accurately ripped
   7   | ( 8/10) Accurately ripped
   8   | (10/10) Accurately ripped
   9   | (10/10) Accurately ripped
  10   | (10/10) Accurately ripped
  11   | (10/10) Accurately ripped
  12   | (10/10) Accurately ripped
  13   | (10/10) Accurately ripped

The new format doesn't contain the detailed entry-per-entry analysis, but should be easier to read when there are many entries.
What do you think, should there be an option to keep the old format or to display both?

Also, wanted to let you know that now there's a Google+ page for CUETools (https://plus.google.com/104483163147049308670/posts), where i will try to post news etc, but no promises. So now you can follow CUETools on Google+, and type +CUETools to mention it in your posts.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-11-10 14:11:50
Personnaly, as long as CTDB is not meant to be a verification database, I prefer the old way. I like seeing the CTDBID.
If readability is the issue, I think the new look is confusing as it is too close to the AR displaying.

I think I also had the Tigerman/Korth problem. I'll post if I encounter it again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-10 14:27:35
Unfortunately, i was not able to reproduce it... Works for me using the same disc.
If this happens again, please provide more details - a copy of your settings etc.
I assume this popup comes after the verify stage. If I try to repair a disc like the example given, the operation just stops after the verify. It will only repair if there is one (and only one) database entry.
Note: I also do not have 'hover' text in the right center of the GUI which includes Action, Mode, Audio Output, and Extra. If there's supposed to be 'hover' text anywhere in there, I don't have it.
I'll PM a copy of my 'settings.txt'
I'm currently working on an update to CTDB. One of the things i wanted to address is the readability of the log.
I'm fine with the old way.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-11-10 14:36:46
Another issue I encountered, when checking an ECD without a log, applying automatically the datatrack length from CTDB doesn't always work if there is several possibilities.

Exemple:
Code: [Select]
[CUETools log; Date: 26/10/11 08:21:54; Version: 2.1.2a]
CD-Extra data track length 00:55:03.
Using preserved id, actual id is 001f1774-010de601-bb12690c.
[CTDB TOCID: 3cZV0hFEMfSJ5v5.YmEtrkFlT8c-] found.
[ CTDBID ] Status
[91454d22] (021/602) Has no data track, No match
[72fa996c] (039/602) Has no data track, Accurately ripped
[a049b78f] (003/602) Accurately ripped
[61e8ba89] (003/602) CD-Extra data track length 01:50:54, No match
[bef8a9b2] (246/602) CD-Extra data track length 02:08:32, Accurately ripped
[72fa996c] (290/602) CD-Extra data track length 02:12:34, Accurately ripped
[AccurateRip ID: 001f2e22-010ef629-bb12b60c] found.
Track  [ CRC ] Status
 01 [0b3270a2] (067/354) Accurately ripped
 02 [7fbb059e] (066/353) Accurately ripped
 03 [f1b71f96] (067/354) Accurately ripped
 04 [4a362c1b] (067/357) Accurately ripped
 05 [b8493eaa] (065/355) Accurately ripped
 06 [0587536a] (066/354) Accurately ripped
 07 [78ae310b] (065/353) Accurately ripped
 08 [9c82d743] (066/355) Accurately ripped
 09 [e8bd9afa] (062/343) Accurately ripped
 10 [33fc3e5b] (067/350) Accurately ripped
 11 [dc0d9566] (061/347) Accurately ripped
AccurateRip v2:
 01 [1f98acd2] (012/354) Accurately ripped
 02 [5591883d] (012/353) Accurately ripped
 03 [9a1d3727] (012/354) Accurately ripped
 04 [662982d6] (012/357) Accurately ripped
 05 [9dd61b33] (012/355) Accurately ripped
 06 [a01b623f] (012/354) Accurately ripped
 07 [26a199e2] (012/353) Accurately ripped
 08 [80056969] (012/355) Accurately ripped
 09 [a2f4a11c] (010/343) Accurately ripped
 10 [55db3a11] (012/350) Accurately ripped
 11 [8cd34ee7] (012/347) Accurately ripped
Offsetted by -744:
 01 [8484299c] (002/354) Accurately ripped
 02 [20cecef4] (002/353) Accurately ripped
 03 [0b1999b1] (002/354) Accurately ripped
 04 [69968dbb] (002/357) Accurately ripped
 05 [ebcffd5a] (002/355) Accurately ripped
 06 [5076b767] (002/354) Accurately ripped
 07 [40df9ad1] (002/353) Accurately ripped
 08 [6cd27da9] (002/355) Accurately ripped
 09 [f212e76e] (002/343) Accurately ripped
 10 [8679d066] (003/350) Accurately ripped
 11 [1a89cf73] (002/347) Accurately ripped
Offsetted by -664:
 01 [6ef70c74] (003/354) Accurately ripped
 02 [1a10532c] (003/353) Accurately ripped
 03 [164377ba] (003/354) Accurately ripped
 04 [2924162e] (003/357) Accurately ripped
 05 [5e511a33] (003/355) Accurately ripped
 06 [ce67d895] (003/354) Accurately ripped
 07 [66eba9d8] (003/353) Accurately ripped
 08 [9ae30ac3] (003/355) Accurately ripped
 09 [efaacd52] (003/343) Accurately ripped
 10 [4070d51f] (003/350) Accurately ripped
 11 [2af27d37] (003/347) Accurately ripped
Offsetted by -12:
 01 [ef56a602] (002/354) Accurately ripped
 02 [72d87bf5] (002/353) Accurately ripped
 03 [582744c0] (002/354) Accurately ripped
 04 [82b7e123] (002/357) Accurately ripped
 05 [2ffd4efd] (002/355) Accurately ripped
 06 [55e3d4aa] (002/354) Accurately ripped
 07 [ac1f41ed] (002/353) Accurately ripped
 08 [bd454d6b] (002/355) Accurately ripped
 09 [5a91189c] (002/343) Accurately ripped
 10 [adb30fbe] (002/350) Accurately ripped
 11 [f2e0b697] (002/347) Accurately ripped
Offsetted by -3:
 01 [15c5f7d8] (002/354) Accurately ripped
 02 [ab86f188] (002/353) Accurately ripped
 03 [0cb07666] (002/354) Accurately ripped
 04 [97bf9169] (002/357) Accurately ripped
 05 [689a3142] (002/355) Accurately ripped
 06 [49f91bfe] (002/354) Accurately ripped
 07 [95f82373] (002/353) Accurately ripped
 08 [5ae5f948] (002/355) Accurately ripped
 09 [c551b9bc] (002/343) Accurately ripped
 10 [c144e3e9] (002/350) Accurately ripped
 11 [21f85c96] (002/347) Accurately ripped
Offsetted by 15:
 01 [b7850cf7] (015/354) Accurately ripped
 02 [616a1db3] (015/353) Accurately ripped
 03 [356c8512] (015/354) Accurately ripped
 04 [2f6af999] (015/357) Accurately ripped
 05 [9229bb94] (015/355) Accurately ripped
 06 [4fbfc1a3] (015/354) Accurately ripped
 07 [46e5736c] (014/353) Accurately ripped
 08 [94bba455] (015/355) Accurately ripped
 09 [98d5088b] (014/343) Accurately ripped
 10 [91a4fb7d] (014/350) Accurately ripped
 11 [7cadbbae] (014/347) Accurately ripped
Offsetted by 18:
 01 [cbcb084c] (012/354) Accurately ripped
 02 [c2411c23] (013/353) Accurately ripped
 03 [5c5f401e] (014/354) Accurately ripped
 04 [8c7e02b9] (014/357) Accurately ripped
 05 [a6124619] (013/355) Accurately ripped
 06 [e79bfad9] (014/354) Accurately ripped
 07 [686e0fcd] (014/353) Accurately ripped
 08 [90623ff8] (014/355) Accurately ripped
 09 [bbceecbe] (013/343) Accurately ripped
 10 [c621d1a8] (013/350) Accurately ripped
 11 [3617f89d] (013/347) Accurately ripped
Offsetted by 611:
 01 [282a7b2d] (003/354) Accurately ripped
 02 [5c1a3c1e] (002/353) Accurately ripped
 03 [f15d09fe] (002/354) Accurately ripped
 04 [2cc66866] (002/357) Accurately ripped
 05 [45861809] (003/355) Accurately ripped
 06 [24393c5c] (003/354) Accurately ripped
 07 [620cddb6] (003/353) Accurately ripped
 08 [892e903d] (003/355) Accurately ripped
 09 [86c3d761] (003/343) Accurately ripped
 10 [b74797b9] (003/350) Accurately ripped
 11 [7c77cd9a] (003/347) Accurately ripped
Offsetted by 652:
 01 [9575c594] (002/354) Accurately ripped
 02 [2aaa54de] (002/353) Accurately ripped
 03 [0712a742] (002/354) Accurately ripped
 04 [2afe7385] (002/357) Accurately ripped
 05 [7225183d] (002/355) Accurately ripped
 06 [ceeb29ee] (002/354) Accurately ripped
 07 [f0299be3] (002/353) Accurately ripped
 08 [e9c9eed0] (002/355) Accurately ripped
 09 [b1c542ae] (002/343) Accurately ripped
 10 [55f49a47] (002/350) Accurately ripped
 11 [a087881a] (002/347) Accurately ripped
Offsetted by 664:
 01 [732a9f99] (200/354) Accurately ripped
 02 [4b01fc6b] (200/353) Accurately ripped
 03 [63b397a5] (200/354) Accurately ripped
 04 [7a2802b3] (200/357) Accurately ripped
 05 [4ae7f527] (200/355) Accurately ripped
 06 [13e096e1] (200/354) Accurately ripped
 07 [806eb128] (200/353) Accurately ripped
 08 [bc92de3e] (200/355) Accurately ripped
 09 [07229deb] (200/343) Accurately ripped
 10 [a9d7bd59] (200/350) Accurately ripped
 11 [610ff51c] (200/347) Accurately ripped
Offsetted by -676:
 01 [cf1d5d3e] (003/354) Accurately ripped
 02 [4c2289ae] (003/353) Accurately ripped
 03 [c17c5a02] (002/354) Accurately ripped
 04 [6c54b9d0] (003/357) Accurately ripped
 05 [7969eb8d] (003/355) Accurately ripped
 06 [94c2f12d] (003/354) Accurately ripped
 07 [07698a87] (003/353) Accurately ripped
 08 [2c3bd852] (003/355) Accurately ripped
 09 [354f484c] (003/343) Accurately ripped
 10 [9ef87c08] (002/350) Accurately ripped
 11 [0a144b26] (000/347) No match but offset
Offsetted by -24:
 01 [68d42047] (000/354) No match but offset
 02 [f353bbf8] (000/353) No match but offset
 03 [1a81f539] (000/354) No match but offset
 04 [a3f3a12d] (002/357) Accurately ripped
 05 [fd73917d] (002/355) Accurately ripped
 06 [8767a515] (002/354) Accurately ripped
 07 [a0e2c57c] (002/353) Accurately ripped
 08 [3ce855fe] (002/355) Accurately ripped
 09 [cb069e14] (000/343) No match but offset
 10 [812dd39f] (000/350) No match but offset
 11 [0796e31a] (002/347) Accurately ripped
Offsetted by 639:
 01 [6a33dc36] (002/354) Accurately ripped
 02 [621610d4] (002/353) Accurately ripped
 03 [d5e7c3a6] (002/354) Accurately ripped
 04 [b6d1de8d] (002/357) Accurately ripped
 05 [9ab25ac1] (002/355) Accurately ripped
 06 [8b81efb9] (002/354) Accurately ripped
 07 [6dbc9dc3] (002/353) Accurately ripped
 08 [146558ba] (002/355) Accurately ripped
 09 [541bd364] (000/343) No match but offset
 10 [d94b0393] (000/350) No match
 11 [4ca1333c] (000/347) No match
Offsetted by 658:
 01 [f24d5c19] (002/354) Accurately ripped
 02 [5d9b64c1] (002/353) Accurately ripped
 03 [5ba98d47] (002/354) Accurately ripped
 04 [d64d7593] (002/357) Accurately ripped
 05 [65b2c353] (002/355) Accurately ripped
 06 [cbf6783d] (000/354) No match but offset
 07 [d57434fe] (000/353) No match but offset
 08 [a10564e8] (000/355) No match but offset
 09 [dc8fef55] (000/343) No match
 10 [00bd8cfd] (000/350) No match
 11 [01313d50] (000/347) No match

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [5988DCC8] [11CC6B60]  
 01  100,0 [71053267] [D93FF8CD]  
 02  98,8 [A800B530] [3A3869FA]  
 03  100,0 [589734A2] [DA6FB712]  
 04  98,8 [76472EEB] [ACF46D0E]  
 05  98,8 [2042AC87] [E51D69B3]  
 06  98,8 [23E4F17E] [64598088]  
 07  98,8 [C4E556FB] [1BC239EB]  
 08  98,8 [60E17B61] [76FA42C7]  
 09  98,8 [22507E2E] [889DE0B7]  
 10  100,0 [D910C174] [43655FB8]  
 11  100,0 [6866F161] [00ECC872]

The interesting part is:
Code: [Select]
CD-Extra data track length 00:55:03.
Using preserved id, actual id is 001f1774-010de601-bb12690c.

The real length is:
CD-Extra data track length 02:12:34.

I noticed this as I have deleted the log but I kept the data track length in an .nfo. (Hoping that at some point you would support a way to check ECD without LOG)

It seems you should tie an ID to each data length to guess which one is correct (if possible) or use a pop up to let the user select (unpractical).

This issue appeared with the recent CTDB boost due to the EAC plugin, it only happens on a handfull very popular CD so far. (This one is by Metallica)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-10 16:25:28
Note: I also do not have 'hover' text in the right center of the GUI which includes Action, Mode, Audio Output, and Extra. If there's supposed to be 'hover' text anywhere in there, I don't have it.
Correction: I do have 'hover' text under 'Action: Correct filenames' in the following two locations.
Mode: Locate files
Mode: Change extension
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-11-10 17:07:52
Ok, i think i got it. You are using mutiselect file browser mode, and in batch modes the popup windows are disabled. When repairing, you have to use Folder browser, and select the actual .cue, not the folder.

And why tooltips aren't showing on your system, i have no idea
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-10 17:42:01
Ok, i think i got it. You are using mutiselect file browser mode, and in batch modes the popup windows are disabled. When repairing, you have to use Folder browser, and select the actual .cue, not the folder.
Confirmed. Works in Folder browser.

And why tooltips aren't showing on your system, i have no idea
Just gave you that info in case it was 'code' related.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-11-10 21:53:55
Personnaly, as long as CTDB is not meant to be a verification database, I prefer the old way. I like seeing the CTDBID.
If readability is the issue, I think the new look is confusing as it is too close to the AR displaying.

CTDB will also be a verification database when it's large enough, and it rapidly becomes large enough.

What do you need to see CTDBID for?

The new look is supposed to look close to AR. That's the point. That's what makes it easier to interpret, because people already know how to read this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-11-11 07:13:42
I don't really need CTDBID for anything I just like to see the mechanics (I like knowing how to split the total matches sum even if not very usefull). If the new look is supposed to look like AR, then yes it does.

I always thought the data within CTDB was too incomplete for verification, like there was not information for each samples/frames but only for selected ones in order to maximize the correction probability versus the needed space to store the audio correction. Was I wrong from start ? Or maybe CTDB store both enought data for a full cheksum verification & partial data for correction ? I need your insight here to understand why CTDB will suddenly become a verification database ? And if really so, why do you still need AR at all ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-11-11 07:20:40
The only thing CTDB didn't have compared to AR was track crcs, and it has them now.
Thanks to Andre, the number of submissions grows very fast, so quite soon CTDB will be able to rely on it's own confidence values and will become completely independent from AR.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-11-11 07:46:44
Be scared Sp n ! It's revolution !
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-11 08:51:05
Gregory, in case you do not hear it enough, thank you for CUETools! It is an excellent, well-done music tool.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 2011-11-11 11:10:39
Why does CT ignore manually edited tags and leaves them as the were found via internet databases?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-11-11 14:46:54
Be scared Sp n ! It's revolution !


Nice colors

To answer - not scared, AccurateRip is soon to be 10 years old (from first concept), and has around 1 billion track submissions in the database, I would like to think that what differentiates AccurateRip from others (there have been 2 which have come and gone over the years) is the effort put in on the backend to keep the crap out, the front end (as you find in EAC or dBpoweramp) is 100x less complex, even with checking across pressings than the backend.

We are giving AccurateRip a push, to be able to verify tracks ripped from any ripper, so the iTunes crowd can quantify what iTunes is really putting out  and possibly to do small scale corrections from what will be one of the largest stores of lossless tracks online.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-11 16:27:17
I would like to think that what differentiates AccurateRip from others (there have been 2 which have come and gone over the years) is the effort put in on the backend to keep the crap out
I do agree that the CTDB could do a better job at keeping the crap out.
I had no control over which rips EAC submitted. Yes I ripped an ISO with EAC. It was the way I stored backups before using EAC. My original was damaged so I had to go to the backup. Yes, I could have deleted the bin file from the AccurateRip folder, but I didn't. Now I submit my rips to the CTDB. Due of your backend, I can't submit to AR anymore.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-11 18:09:39
Sorry, called away before I could edit.
My point was that all my rips are now considered crap by AR regardless of whether or not they actually are. Your backend is a little too unforgiving.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-11-11 19:43:49
If none of your rips match AR then AR cannot be any more forgiving, they either match or they do not, if you are using a program which cannot check across pressings, then check your cd ripping offset is correct.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-11-11 20:46:20
Why does CT ignore manually edited tags and leaves them as the were found via internet databases?

If i recall correctly, this was a bug in 2.1.2, fixed in 2.1.2a
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-11-11 20:57:51

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-11 22:40:01
If none of your rips match AR then AR cannot be any more forgiving, they either match or they do not, if you are using a program which cannot check across pressings, then check your cd ripping offset is correct.
I was referring to rip submissions never appearing in the AR database or your backend blocking submissions by ComputerID. (My original post needed editing, sorry for the confusion). This is off-topic, I'll drop it. I no longer submit to AR anyway. Why bother if the data is ignored.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2011-11-12 10:18:05
and in batch modes the popup windows are disabled. When repairing, you have to use Folder browser, and select the actual .cue, not the folder.

Thanks for the clarification. I always use drag'n drop mode. That can be called a batch mode too, so that was the reason I didn't get the pop-up.
Now I can repair some rips 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-12 22:31:27
How do I rip a CD using CUERipper and go to individual tracks -- but without the occasional HTOA file getting written as a small (silent) "track"?

I want to be able to prepend or append those gaps (HTOA tracks) to existing tracks, but I cannot see how to adjust that setting.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-11-13 01:02:40
How do I rip a CD using CUERipper and go to individual tracks -- but without the occasional HTOA file getting written as a small (silent) "track"?
I want to be able to prepend or append those gaps (HTOA tracks) to existing tracks, but I cannot see how to adjust that setting.
Thank you.
If you are asking about switching the 'Gap Handling' from 'Gaps Appended + HTOA' to 'Gaps Appended' so pregaps are not written as HTOA, it is handled by
%appdata%/CUERipper/settings.txt
PreserveHTOA=1 is for 'Gaps Appended + HTOA'
PreserveHTOA=0 is for 'Gaps Appended' only

Changing 'Gap Handling' to 'Gaps Appended' can change the log results if the pregap isn't completely silent. AR ignores this but the CTDB doesn't. You may also miss actual Hidden Track One Audio.
I've requested a setting that would treat silence as pregap and nonsilence as HTOA but Gregory didn't acknowledge it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-13 07:06:27
Thanks, korth. You are a wealth of knowledge!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-13 16:08:16
I'm inputting label data into the meta field box of CUERipper 2.1.2 and I am not seeing that data get transferred either to the CUE sheet or the individually ripped tracks. Is this omission a bug, or am I missing something?

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2011-11-14 00:12:40
To answer - not scared, AccurateRip is soon to be 10 years old (from first concept), and has around 1 billion track submissions in the database, I would like to think that what differentiates AccurateRip from others (there have been 2 which have come and gone over the years) is the effort put in on the backend to keep the crap out, the front end (as you find in EAC or dBpoweramp) is 100x less complex, even with checking across pressings than the backend.


I don't know how updated are the statistics from AccurateRip website, but it says 2 million unique discs. CTDB has only 8 weeks of EAC support and it has 10% of what AR has. Definitively it will slow down as it will approach AR numbers, but soon this will not be an issue anymore. Next year no one will care witch is bigger, only the features will matter.

Don't get me wrong, I appreciate AR, but I don't like your answer: "We are so big that we don't fear anyone, we do not need to step up our game". With this attitude you are going nowhere.

Please be more competitive, we will all benefit.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2011-11-14 09:12:34
>we do not need to step up our game

It is going to take about 6 to 8 months of work to be able to verify individual tracks without TOCs against AccurateRip and to be able to correct them, if this amount of effort if not being competitive, I do not know what is.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tremmz on 2011-11-22 06:26:42
Hi,
I'm completely new at ripping .flac files, and read that cueripper was a good and simple software to use. So I have it and now have two questions, which I have circled in yellow. What are these sliders and how should they be set? 



Hope this is the right place for this question.?.?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: A_Man_Eating_Duck on 2011-11-22 08:47:19
The slider on the left is the compression, normally Flac only goes from 0 - 8, but using the libFlake you can a little more compression when using 9 - 11. you can read more about the Flake encoder HERE (http://flake-enc.sourceforge.net/).

The slider on the right is the ripping method. Secure means that the track is is read twice and the checksums are compared to see if the rip is clean. Paranoid mode will rip the track 4 times and compare the checksums of each rip to make sure they match. You can see below in the window tray where it says 6, this means that the disc in the the accurip database. This means that 6 other people have ripped the disc and your rip with be compared against their results to make sure your rip is clean.

Correct me if I'm wrong about the ripping methods 

The setting in the screenshot look fine to use for your ripping.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tremmz on 2011-11-22 09:22:47
Thanks A_Man_Eating_Duck, appreciate your input 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: philaphonic on 2011-11-22 09:47:20
Thanks A_Man_Eating_Duck, appreciate your input 


I'd change libFlake to libFLAC, move the slider to 8 and leave the EAC log at "Secure"... Anything more is overkill. In fact, "Burst" would be fine, as long as the AccurateRip results indicate a good rip.

I have had problems playing back libFlake-encoded tracks using compression setting 11.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Manlord on 2011-11-24 02:21:45
A little feature request to Gregory 

I would like Cuetools to be able to create multiple ARTIST (also applies to GENRE) tags in order to be compatible with FLAC recommended way of tagging (also applies for APE tags).

Let's see the following example:

Quote
FILE "13 The Calling _ Day of Celebration.tak" WAVE
  TRACK 13 AUDIO
    TITLE "The Calling / Day of Celebration"
    PERFORMER "Santana; Eric Clapton"
    INDEX 01 00:00:00


The aplication would see "; " as a separator and write 2 artist tags
ARTIST Santana
ARTIST Eric Clapton

I have doubts about what would be the best separator to use:
ID3 tags uses " / "
Foobar uses "; "
Mp3tag uses "\\"

I would bet for " / " for being compatible with ID3 Tag but the problem comes when you want to convert to MP3, since "ARTIST Santa / Eric Clapton" would be compatible with the specs but in this way two tags would be written. Maybe the best solution would be to implement it just when converting to a lossless format, or just when converting to certain types of tags (vorbis and ape).

Would like to know your opinions on the issue.

Kind regards,

Manlord
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2011-11-24 02:58:58
CUETools uses TagLib library (https://github.com/mono/taglib-sharp), which is in theory capable of handling multiple artist tags (using ';' as a separator when needed). But i try to avoid this.
Lack of universal standards for tags makes it a huge mess. Every metadata database, every file format, every audio player has it's own conventions.
CUETools has to deal with 3 metadata databases (musicbrainz, freedb, discogs), 4 major file/tag format families (vorbis(flac/ogg), id3v1/v2(mp3,ape), mpeg4(m4a), cue), and an unknown set of audio players.
For now i try to avoid complicated stuff like multiple artist tags, and keep it simple.

Musicbrainz and discogs return list of artists together with list of separators, e.g. 'Simon',  ' & ', 'Garfunkel' or 'Tom Petty', ' and ', 'The Heartbreakers'. This is very cool, but i don't know of any tag format or audio player capable of handling this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Manlord on 2011-11-26 15:50:27
I understand your position Gregory, I will continue to do a 2 step method.

Quote
Musicbrainz and discogs return list of artists together with list of separators, e.g. 'Simon', ' & ', 'Garfunkel' or 'Tom Petty', ' and ', 'The Heartbreakers'. This is very cool, but i don't know of any tag format or audio player capable of handling this.


Indeed that is the most convenient solution, but with the agreements that exists about tags I doubt it will be implemented some day.

By the way, any plans to support editing per track artist when syncing to Musicbrainz or freedb?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: staringfrog on 2011-11-26 15:52:17
A hodgepodge piece of amateur software, in Russian-Canadian style. Guys, use professional applications like EAC, for Christ sake.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: frozenspeed on 2011-11-26 16:01:43
A hodgepodge piece of amateur software, in Russian-Canadian style. Guys, use professional applications like EAC, for Christ sake.


Bigotry and blasphemy aside, how is EAC any more or less "professional"?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2011-11-27 13:38:55
To answer - not scared, AccurateRip is soon to be 10 years old (from first concept), and has around 1 billion track submissions in the database, I would like to think that what differentiates AccurateRip from others (there have been 2 which have come and gone over the years) is the effort put in on the backend to keep the crap out, the front end (as you find in EAC or dBpoweramp) is 100x less complex, even with checking across pressings than the backend.



This is all OT and would be better in the CTDB thread.
Both have their place and I still wish dBpoweramp would add support for CTDB. I know Gregory looked at adding it through the open DSP but apparently it is not documented clearly enough and does not have enough access to work back and forth with dBpoweramp.

Quote
We are giving AccurateRip a push, to be able to verify tracks ripped from any ripper, so the iTunes crowd can quantify what iTunes is really putting out  and possibly to do small scale corrections from what will be one of the largest stores of lossless tracks online.


Spoon, are you looking at AR doing some RS based repairs in a manner similar to CTDB?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-12-02 20:32:55
After switching back from x64 to x32 Windows on my netbook I've got following error using FLACCL:

(http://i32.fastpic.ru/big/2011/1202/98/665ec05ab60ab6ceacaa494b0b7b2398.jpg)

Some flac files are written correctly, but not all tracks.

libFLAC produced all files without errors.

Any advice?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2011-12-03 18:56:00
Hi:

I've used CueTools on 32-bit systems, and always download ffmpeg.exe to be able to output ALAC.

Now I'm "installing" on Windows 7 Home Premium 64-bit.  Do I need to do anything different with CueTools?

What about ffmpeg.exe?
http://sourceforge.net/projects/mplayer-win32/files/ (http://sourceforge.net/projects/mplayer-win32/files/) has just ffmpeg.exe for 32-bit Windows. Is there a more suitable ffmpeg.exe somewhere that works better on 64-bit systems?

Or, is ffmpeg.exe even still required? Is the current version of CueTools able to read and output ALAC without the need of getting a separate encoder?

Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2011-12-03 20:51:45
How can I change the output folder?
I clicked the icon next to Output, but it won't let me select “Browse”. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-12-03 23:53:01
How can I change the output folder?
I clicked the icon next to Output, but it won't let me select “Browse”.
'Browse' should be available when the Input is either 'Folder browser' or 'Hide browser'. 'Multiselect Browser' and 'Drag'n'drop mode' require a 'template' because more than one disc can be selected.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2011-12-04 00:36:43
Gregory,

Can you please add support for XLD logs when cross checking the calculated CRC values against the values from log.

Also, this log:

Code: [Select]
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 8. October 2009, 17:21

Various / Diggin In The Crates - Rare Studio Masters: 1993-1997

Used drive  : LITE-ON COMBO SOHC-4836K  Adapter: 4  ID: 0

Read mode   : Secure
Utilize accurate stream : Yes
Defeat audio cache   : Yes
Make use of C2 pointers : Yes

Read offset correction   : 6
Overread into Lead-In and Lead-Out   : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations   : Yes
Used interface   : Native Win32 interface for Win NT & 2000
Gap handling : Appended to previous track

Used output format   : User Defined Encoder
Selected bitrate : 320 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files\Exact Audio Copy\Flac\flac.exe
Additional command line options : -V -8 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


TOC of the extracted CD

Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  |  0:00.00 |  4:18.54 | 0 | 19403 
2  |  4:18.54 |  3:43.72 | 19404 | 36200 
3  |  8:02.51 |  4:14.73 | 36201 | 55323 
4  | 12:17.49 |  4:10.57 | 55324 | 74130 
5  | 16:28.31 |  4:33.02 | 74131 | 94607 
6  | 21:01.33 |  4:30.01 | 94608 |  114858 
7  | 25:31.34 |  4:01.74 | 114859 |  133007 
8  | 29:33.33 |  3:34.14 | 133008 |  149071 
9  | 33:07.47 |  4:27.48 | 149072 |  169144 
  10  | 37:35.20 |  4:06.11 | 169145 |  187605 
  11  | 41:41.31 |  4:33.35 | 187606 |  208115 
  12  | 46:14.66 |  3:22.61 | 208116 |  223326 
  13  | 49:37.52 |  3:35.74 | 223327 |  239525 
  14  | 53:13.51 |  4:38.54 | 239526 |  260429 
  15  | 57:52.30 |  3:41.33 | 260430 |  277037 
  16  | 61:33.63 |  3:22.72 | 277038 |  292259 
  17  | 64:56.60 |  2:38.61 | 292260 |  304170 
  18  | 67:35.46 |  3:17.67 | 304171 |  319012 
  19  | 70:53.38 |  4:04.21 | 319013 |  337333 
  20  | 74:57.59 |  4:17.27 | 337334 |  356635 


Track 13

Filename D:\Transportation Folder\music\EACRips\The Lump Lump [Nubian Mix] [Featuring Brand Nubian].wav

Peak level 93.8 %
Track quality 100.0 %
Test CRC FF237B77
Copy CRC FF237B77
Accurately ripped (confidence 1)  [C55AC37B]
Copy OK


All tracks accurately ripped

No errors occurred

End of status report

------------------------------------------------------------

Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 8. October 2009, 17:58

Various / Diggin In The Crates - Rare Studio Masters: 1993-1997

Used drive  : LITE-ON COMBO SOHC-4836K  Adapter: 4  ID: 0

Read mode   : Secure
Utilize accurate stream : Yes
Defeat audio cache   : Yes
Make use of C2 pointers : Yes

Read offset correction   : 6
Overread into Lead-In and Lead-Out   : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations   : Yes
Used interface   : Native Win32 interface for Win NT & 2000
Gap handling : Appended to previous track

Used output format   : User Defined Encoder
Selected bitrate : 320 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files\Exact Audio Copy\Flac\flac.exe
Additional command line options : -V -8 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


TOC of the extracted CD

Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  |  0:00.00 |  4:18.54 | 0 | 19403 
2  |  4:18.54 |  3:43.72 | 19404 | 36200 
3  |  8:02.51 |  4:14.73 | 36201 | 55323 
4  | 12:17.49 |  4:10.57 | 55324 | 74130 
5  | 16:28.31 |  4:33.02 | 74131 | 94607 
6  | 21:01.33 |  4:30.01 | 94608 |  114858 
7  | 25:31.34 |  4:01.74 | 114859 |  133007 
8  | 29:33.33 |  3:34.14 | 133008 |  149071 
9  | 33:07.47 |  4:27.48 | 149072 |  169144 
  10  | 37:35.20 |  4:06.11 | 169145 |  187605 
  11  | 41:41.31 |  4:33.35 | 187606 |  208115 
  12  | 46:14.66 |  3:22.61 | 208116 |  223326 
  13  | 49:37.52 |  3:35.74 | 223327 |  239525 
  14  | 53:13.51 |  4:38.54 | 239526 |  260429 
  15  | 57:52.30 |  3:41.33 | 260430 |  277037 
  16  | 61:33.63 |  3:22.72 | 277038 |  292259 
  17  | 64:56.60 |  2:38.61 | 292260 |  304170 
  18  | 67:35.46 |  3:17.67 | 304171 |  319012 
  19  | 70:53.38 |  4:04.21 | 319013 |  337333 
  20  | 74:57.59 |  4:17.27 | 337334 |  356635 


Track  1

Filename D:\Transportation Folder\music\EACRips\Bring It On [Remix].wav

Pre-gap length  0:00:02.00

Peak level 95.5 %
Track quality 100.0 %
Test CRC E1DB0FFA
Copy CRC E1DB0FFA
Accurately ripped (confidence 1)  [15F12A21]
Copy OK

Track  2

Filename D:\Transportation Folder\music\EACRips\You Know Now [Remix].wav

Peak level 99.9 %
Track quality 100.0 %
Test CRC 11DC7E8A
Copy CRC 11DC7E8A
Accurately ripped (confidence 1)  [D7D19EA9]
Copy OK

Track  3

Filename D:\Transportation Folder\music\EACRips\Caught Up in the Game.wav

Peak level 99.9 %
Track quality 99.9 %
Test CRC 70E20EC9
Copy CRC 70E20EC9
Accurately ripped (confidence 1)  [6A4B44B5]
Copy OK

Track  4

Filename D:\Transportation Folder\music\EACRips\Respect the Architect [Remix] [Featuring Bahamadia].wav

Peak level 99.9 %
Track quality 100.0 %
Test CRC 10C12DDE
Copy CRC 10C12DDE
Accurately ripped (confidence 1)  [DEA84470]
Copy OK

Track  5

Filename D:\Transportation Folder\music\EACRips\Daaam! [Remix].wav

Peak level 92.8 %
Track quality 100.0 %
Test CRC 91332F1C
Copy CRC 91332F1C
Accurately ripped (confidence 1)  [5BABBDE7]
Copy OK

Track  6

Filename D:\Transportation Folder\music\EACRips\Problemz.wav

Peak level 99.9 %
Track quality 100.0 %
Test CRC DE393D21
Copy CRC DE393D21
Accurately ripped (confidence 1)  [323FBB65]
Copy OK

Track  7

Filename D:\Transportation Folder\music\EACRips\Rockin’ It.wav

Peak level 99.9 %
Track quality 100.0 %
Test CRC FFB7D5F7
Copy CRC FFB7D5F7
Accurately ripped (confidence 1)  [F8BAE829]
Copy OK

Track  8

Filename D:\Transportation Folder\music\EACRips\MVP [Remix #2].wav

Peak level 99.9 %
Track quality 99.9 %
Test CRC 9E1329B5
Copy CRC 9E1329B5
Accurately ripped (confidence 1)  [9E39A0CE]
Copy OK

Track  9

Filename D:\Transportation Folder\music\EACRips\North South East West [Remix].wav

Peak level 100.0 %
Track quality 100.0 %
Test CRC 22C3E1C4
Copy CRC 22C3E1C4
Accurately ripped (confidence 1)  [BCD16C8E]
Copy OK

Track 10

Filename D:\Transportation Folder\music\EACRips\Story of My Life.wav

Peak level 99.9 %
Track quality 100.0 %
Test CRC 7EF48E77
Copy CRC 7EF48E77
Accurately ripped (confidence 1)  [DFAD6256]
Copy OK

Track 11

Filename D:\Transportation Folder\music\EACRips\You Can’t Front [Featuring Lord Finesse and Sadat X].wav

Peak level 90.7 %
Track quality 99.9 %
Test CRC 7AD5C362
Copy CRC 7AD5C362
Accurately ripped (confidence 1)  [11CD821B]
Copy OK

Track 12

Filename D:\Transportation Folder\music\EACRips\Life’s a Bitch [Remix #2] [Featuring AZ].wav

Peak level 99.9 %
Track quality 100.0 %
Test CRC 41D842ED
Copy CRC 41D842ED
Accurately ripped (confidence 1)  [4680D18E]
Copy OK

Track 13

Filename D:\Transportation Folder\music\EACRips\The Lump Lump [Nubian Mix] [Featuring Brand Nubian].wav

Peak level 93.8 %
Track quality 100.0 %
Test CRC FF237B77
Copy CRC FF237B77
Accurately ripped (confidence 1)  [C55AC37B]
Copy OK

Track 14

Filename D:\Transportation Folder\music\EACRips\Lyrics [Remix].wav

Peak level 100.0 %
Track quality 100.0 %
Test CRC A2ACA0D3
Copy CRC A2ACA0D3
Accurately ripped (confidence 1)  [3739A3BD]
Copy OK

Track 15

Filename D:\Transportation Folder\music\EACRips\Mad Izm ['95 Remix].wav

Peak level 99.9 %
Track quality 99.2 %
Test CRC 69F96744
Copy CRC 69F96744
Accurately ripped (confidence 1)  [207ED13D]
Copy OK

Track 16

Filename D:\Transportation Folder\music\EACRips\Cut That Weak Shit [Remix] [Featuring Kwaze Modoe and Royal Flush].wav

Peak level 100.0 %
Track quality 100.0 %
Test CRC BBBB801A
Copy CRC BBBB801A
Accurately ripped (confidence 1)  [50085E7B]
Copy OK

Track 17

Filename D:\Transportation Folder\music\EACRips\Love Child.wav

Peak level 91.2 %
Track quality 100.0 %
Test CRC 93C15DD0
Copy CRC 93C15DD0
Accurately ripped (confidence 1)  [2F48F58A]
Copy OK

Track 18

Filename D:\Transportation Folder\music\EACRips\Guess Who’s Back  [Remix].wav

Peak level 79.3 %
Track quality 100.0 %
Test CRC C504CF40
Copy CRC C504CF40
Accurately ripped (confidence 1)  [D28482D3]
Copy OK

Track 19

Filename D:\Transportation Folder\music\EACRips\The Difference.wav

Peak level 99.7 %
Track quality 100.0 %
Test CRC CFFC2800
Copy CRC CFFC2800
Accurately ripped (confidence 1)  [A8C789BB]
Copy OK

Track 20

Filename D:\Transportation Folder\music\EACRips\I Be [Remix].wav

Peak level 99.9 %
Track quality 100.0 %
Test CRC D2CC24CF
Copy CRC D2CC24C
Accurately ripped (confidence 1)  [9608E61A]
Copy OK


All tracks accurately ripped

No errors occurred

End of status report

gives this result:

Code: [Select]
[CUETools log; Date: 11/28/2011 12:35:19 AM; Version: 2.1.2a]
[CTDB TOCID: Sni6BQSyPWfYy4WIratT49CZjfs-] found.
[ CTDBID ] Status
[fc346744] (3/3) Accurately ripped
[AccurateRip ID: 003ac3c9-03581ae2-63129314] found.
Track  [ CRC ] Status
 01 [15f12a21] (3/3) Accurately ripped
 02 [d7d19ea9] (3/3) Accurately ripped
 03 [6a4b44b5] (3/3) Accurately ripped
 04 [dea84470] (3/3) Accurately ripped
 05 [5babbde7] (3/3) Accurately ripped
 06 [323fbb65] (3/3) Accurately ripped
 07 [f8bae829] (3/3) Accurately ripped
 08 [9e39a0ce] (3/3) Accurately ripped
 09 [bcd16c8e] (3/3) Accurately ripped
 10 [dfad6256] (3/3) Accurately ripped
 11 [11cd821b] (3/3) Accurately ripped
 12 [4680d18e] (3/3) Accurately ripped
 13 [c55ac37b] (3/3) Accurately ripped
 14 [3739a3bd] (3/3) Accurately ripped
 15 [207ed13d] (3/3) Accurately ripped
 16 [50085e7b] (3/3) Accurately ripped
 17 [2f48f58a] (3/3) Accurately ripped
 18 [d28482d3] (3/3) Accurately ripped
 19 [a8c789bb] (3/3) Accurately ripped
 20 [9608e61a] (3/3) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [41E90A22] [30DB2FA7]  
 01  95.5 [E1DB0FFA] [4C93568A] [FF237B77]: CRC32 for track 13
 02  99.9 [11DC7E8A] [9430DF94] [E1DB0FFA]: CRC32 for track 1
 03  99.9 [70E20EC9] [0CE504C1] [11DC7E8A]: CRC32 for track 2
 04  99.9 [10C12DDE] [D2CE7E0C] [70E20EC9]: CRC32 for track 3
 05  92.8 [91332F1C] [5FAA2C0D] [10C12DDE]: CRC32 for track 4
 06  99.9 [DE393D21] [C0A4441B] [91332F1C]: CRC32 for track 5
 07  99.9 [FFB7D5F7] [76BF93CE] [DE393D21]: CRC32 for track 6
 08  99.9 [9E1329B5] [FAFD9C98] [FFB7D5F7]: CRC32 for track 7
 09  100.0 [22C3E1C4] [1802AB60] [9E1329B5]: CRC32 for track 8
 10  99.9 [7EF48E77] [02B7C375] [22C3E1C4]: CRC32 for track 9
 11  90.7 [7AD5C362] [69D22E63] [7EF48E77]: CRC32 for track 10
 12  99.9 [41D842ED] [9B2D246D] [7AD5C362]: CRC32 for track 11
 13  93.8 [FF237B77] [40269DC6] [41D842ED]: CRC32 for track 12
 14  100.0 [A2ACA0D3] [37C7D3FA] [FF237B77]: CRC32 for track 13
 15  99.9 [69F96744] [CDDB47C6] [A2ACA0D3]: CRC32 for track 14
 16  100.0 [BBBB801A] [4F181A17] [69F96744]: CRC32 for track 15
 17  91.2 [93C15DD0] [ED833F35] [BBBB801A]: CRC32 for track 16
 18  79.3 [C504CF40] [39A86EC3] [93C15DD0]: CRC32 for track 17
 19  99.7 [CFFC2800] [69DFDDDE] [C504CF40]: CRC32 for track 18
 20  99.9 [D2CC24CF] [EA552F37] [CFFC2800]: CRC32 for track 19

Maybe you can also fix this. It shouldn't be complicated.

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2011-12-04 03:37:50
How can I change the output folder?
I clicked the icon next to Output, but it won't let me select “Browse”.


'Browse' should be available when the Input is either 'Folder browser' or 'Hide browser'. 'Multiselect Browser' and 'Drag'n'drop mode' require a 'template' because more than one disc can be selected.

Thanks. Setting that Output folder is fiddly. I changed to 'Folder browser', navigated the tree and double-clicked a folder or somehow selected it. Somehow it caused CueTools to rename my folder to "My Music". I deleted that folder, and recreated my original folder. Again, through navigating somehow magically Output now shows the path I wanted, but I'm not sure how I did it.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wildsnake on 2011-12-04 12:12:52
(http://s017.radikal.ru/i401/1112/e0/1460265840b8.jpg)
(http://s017.radikal.ru/i401/1112/42/dfd2e0edf545.jpg)

this problem appeared some time ago, before that everything was good.
i can convert only one album in batch mode, then one of those errors appears.
OpenCL - AMD APP. CPU - Phenon 9550
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2011-12-04 13:15:04
I replaced built-in FLACCL with version 0.4 (exe with command-line parameters). All files were written without any error message. :-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wildsnake on 2011-12-04 15:19:50
i did the same as you, but still got errors.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-11 05:16:15
Good day.

I recently ripped a CD with EAC (1 bad track; with my Pioneer DVD this is VERY frequent even on pristine CDs) and got curious about a bit at the end of EAC's log that mentionned I could repair the rip with CUETools. So I installed CT and several hours later, I repaired the bad track. Now here's the funny part, I re-verified the repaired CD and I noticed that for the repaired track, the LOG column in accurip's log is still different than all the other tracks - How can it be different, if the track is repaired shouldn't I see "CRC32" in that column?

Here's the verify log (this is a verify of the repaired CD) - Notice that now all tracks are "accurately ripped" (Track #11 was no match before the repair) but also notice for Track #11, at the bottom of the log, how it as a CRC in the "LOG" column instead of the word "CRC32":

Code: [Select]
[CUETools log; Date: 2011-12-10 14:29:44; Version: 2.1.2a]
[CTDB TOCID: RphOu8zFqN8urSL9dgCcCc.eJw4-] found.
        [ CTDBID ] Status
        [9a7c658f] (40/40) Accurately ripped
[AccurateRip ID: 002059de-0142cf9a-b60fc70d] found.
Track  [ CRC    ] Status
 01    [3d4b3ecd] (43/48) Accurately ripped
 02    [2fcc4a72] (44/49) Accurately ripped
 03    [e4623e80] (44/49) Accurately ripped
 04    [41d701e1] (44/49) Accurately ripped
 05    [925ce0ab] (44/49) Accurately ripped
 06    [4c8ba048] (43/48) Accurately ripped
 07    [7d5d262d] (44/49) Accurately ripped
 08    [9204c60b] (43/48) Accurately ripped
 09    [a19bdd39] (42/47) Accurately ripped
 10    [54b393fa] (41/46) Accurately ripped
 11    [394d2c39] (41/46) Accurately ripped
 12    [51e27348] (44/49) Accurately ripped
 13    [fbb54872] (41/48) Accurately ripped
AccurateRip v2:
 01    [df71b6dc] (05/48) Accurately ripped
 02    [8d5715f1] (05/49) Accurately ripped
 03    [a32b3e53] (05/49) Accurately ripped
 04    [0df00ef9] (05/49) Accurately ripped
 05    [736d9c5f] (05/49) Accurately ripped
 06    [b1b27c8c] (05/48) Accurately ripped
 07    [f5172bcc] (05/49) Accurately ripped
 08    [3012cc94] (05/48) Accurately ripped
 09    [0936db11] (05/47) Accurately ripped
 10    [80d7d66d] (05/46) Accurately ripped
 11    [8a750164] (05/46) Accurately ripped
 12    [2c577ea9] (05/49) Accurately ripped
 13    [609ecad2] (05/48) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  99.9 [9A01E1DB] [98AFC778]         
 01  99.9 [649F0294] [4893435D]  CRC32 
 02  99.9 [3CA35CD6] [6D879D3D]  CRC32 
 03  99.9 [3EE18882] [5E33A531]  CRC32 
 04  99.9 [3DAD00F8] [62E8E57C]  CRC32 
 05  99.9 [9FEBA1A9] [E970764B]  CRC32 
 06  99.9 [EE4D5485] [66F1747A]  CRC32 
 07  99.9 [4159AD04] [7CE498DD]  CRC32 
 08  99.9 [176884D2] [FBDCBAD5]  CRC32 
 09  99.9 [7DB7747F] [7FE2184C]  CRC32 
 10  99.9 [422F708B] [F6A80CA3]  CRC32 
 11  99.9 [3BD1FD8D] [119E2454] [8727C71E] <-- Why is this track still different?
 12  99.9 [D2DE2076] [611E0883]  CRC32 
 13  99.9 [CF700673] [DE531C8B]  CRC32

Also, can you guys help me readthose CT logs, specifically:

[CTDB TOCID: RphOu8zFqN8urSL9dgCcCc.eJw4-] found. <-- Table of Content ID, this I get.
        [ CTDBID ] Status <-- Why is CTDBID (9a7c658f) not same as TOCID?
        [9a7c658f] (40/40) Accurately ripped <-- What does this mean? Does this mean my rip is accurate?
[AccurateRip ID: 002059de-0142cf9a-b60fc70d] found. <-- Yet another ID, how many IDs does each CD have?
Track  [ CRC    ] Status
 01    [3d4b3ecd] (43/48) Accurately ripped <-- Is this a compare against "AccurateRip ID: 002059de-0142cf9a-b60fc70d" ?
 13    [fbb54872] (41/48) Accurately ripped
AccurateRip v2: <-- What does this mean, why does it NOT say "AccurateRip v2 ID: blabla", there's no ID in v2?
...

I realize I'm asking a lot, but while I understand the lines that display each track's accuracy, most of the rest of the log I do not understand. Why so many IDs (TOCID, CTDBID, AccurateRip ID), why no ID next to "AccurateRip v2" and for that matter, why v1 and v2? And what does that LOG column mean at the end of the log?

Thank you much for any help.
Best Regards,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-12-11 15:07:20
Wow that's a lot of questions. You couldn't find the answers somewhere in the other 67 pages?

How can it be different, if the track is repaired shouldn't I see "CRC32" in that column?
This can be found [a href='index.php?act=findpost&pid=616364']here[/a]. This section is provided for checking the files you have against the EAC log file found in the same folder as the files. It is telling you that (after repair) the CRC found in your EAC log file for track 11 is different than the actual file CRC.

Quote
[ CTDBID ] Status <-- Why is CTDBID (9a7c658f) not same as TOCID?
This can be found [a href='index.php?act=findpost&pid=703224']here[/a].

Quote
[AccurateRip ID: 002059de-0142cf9a-b60fc70d] found. <-- Yet another ID, how many IDs does each CD have?
Different database. This section of the log is from the AccurateRip database (used by permission).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-11 19:17:11
Thanks alot for the lesson, I'd read the first ~10 pages and quit; I will go read the other 57 pages...

Best Regards,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-11 23:17:33
Good day.

Alright, I've started reading this thread again (I'm at page 14 right now, this is taking forever!) while ripping CDs with EAC and I just noticed something. Are any of you aware of some issue with the CueTools plugin in EAC where it does not get called at all for some rips? I find that being able to repair rips is just awesome, and so I want to make sure I participate in submitting to CueTools whenever EAC does a good rip. However, sometimes there is no CueTools text at the bottom of the EAC log at all. Anyone know why?

Here's the EAC log in question; the rip is accurate, and not found in CTDB (I verified with CueTools) yet no CueTools entry at bottom of EAC log:

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 11. December 2011, 16:16

Rush / Power Windows

Used drive  : PIONEER DVD-RW  DVR-116D  Adapter: 0  ID: 1

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 96
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format              : User Defined Encoder
Selected bitrate                : 768 kBit/s
Quality                        : High
Add ID3 tag                    : No
Command line compressor        : E:\Apps\WinXp\Media\EAC\FLAC\FLAC.EXE
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "BAND=%albuminterpret%" -T "ALBUMARTIST=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" %hascover%--picture="%coverfile%"%hascover% %source% -o %dest%


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.33 |  5:37.05 |        33    |    25312 
        2  |  5:37.38 |  5:06.37 |    25313    |    48299 
        3  | 10:44.00 |  5:07.38 |    48300    |    71362 
        4  | 15:51.38 |  6:11.42 |    71363    |    99229 
        5  | 22:03.05 |  6:20.38 |    99230    |  127767 
        6  | 28:23.43 |  5:15.60 |    127768    |  151452 
        7  | 33:39.28 |  5:10.62 |    151453    |  174764 
        8  | 38:50.15 |  5:55.28 |    174765    |  201417 


Track  1

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 01 - The Big Money.wav

    Pre-gap length  0:00:02.33

    Peak level 97.7 %
    Extraction speed 4.7 X
    Track quality 100.0 %
    Test CRC D59C2942
    Copy CRC D59C2942
    Accurately ripped (confidence 3)  [93C07912]  (AR v1)
    Copy OK

Track  2

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 02 - Grand Designs.wav

    Pre-gap length  0:00:00.70

    Peak level 83.6 %
    Extraction speed 2.9 X
    Track quality 99.7 %
    Test CRC 4D7083B1
    Copy CRC 4D7083B1
    Accurately ripped (confidence 3)  [C4BBED12]  (AR v1)
    Copy OK

Track  3

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 03 - Manhattan Project.wav

    Pre-gap length  0:00:00.27

    Peak level 92.0 %
    Extraction speed 5.7 X
    Track quality 100.0 %
    Test CRC F6E1D407
    Copy CRC F6E1D407
    Accurately ripped (confidence 3)  [775D8EF2]  (AR v1)
    Copy OK

Track  4

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 04 - Marathon.wav

    Pre-gap length  0:00:02.47

    Peak level 78.1 %
    Extraction speed 5.9 X
    Track quality 99.9 %
    Test CRC 5A16693B
    Copy CRC 5A16693B
    Accurately ripped (confidence 3)  [50D9CE95]  (AR v1)
    Copy OK

Track  5

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 05 - Territories.wav

    Pre-gap length  0:00:01.59

    Peak level 78.8 %
    Extraction speed 6.3 X
    Track quality 99.9 %
    Test CRC F9E4B3C2
    Copy CRC F9E4B3C2
    Accurately ripped (confidence 3)  [93EDCC52]  (AR v1)
    Copy OK

Track  6

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 06 - Middletown Dreams.wav

    Pre-gap length  0:00:01.07

    Peak level 78.4 %
    Extraction speed 5.8 X
    Track quality 99.9 %
    Test CRC FBDBDEE1
    Copy CRC FBDBDEE1
    Accurately ripped (confidence 3)  [ED6A9F3D]  (AR v1)
    Copy OK

Track  7

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 07 - Emotion Detector.wav

    Pre-gap length  0:00:00.02

    Peak level 91.3 %
    Extraction speed 7.3 X
    Track quality 100.0 %
    Test CRC 6EFD2BD3
    Copy CRC 6EFD2BD3
    Accurately ripped (confidence 3)  [4D4F40EB]  (AR v1)
    Copy OK

Track  8

    Filename F:\Data\Public\RECODE\Rush - Power Windows - 08 - Mystic Rythms.wav

    Pre-gap length  0:00:00.67

    Peak level 85.6 %
    Extraction speed 3.0 X
    Track quality 99.8 %
    Test CRC 64F48D47
    Copy CRC 64F48D47
    Accurately ripped (confidence 3)  [ECE4AA53]  (AR v1)
    Copy OK


All tracks accurately ripped

No errors occurred

End of status report

==== Log checksum 98AA8AA90805A95CA9140AE9E8C59332863B702BC6EB8D9177DD9BE9B5114091 ====
Is this a bug in EAC? Is there a thread on Hydrogen just for the EAC plugin? This happens alot where there is no CueTools entry at end of EAC log :-(

For now I re-rip such CDs with CueRipper just so it gets submitted (then discard the rip, I've already ripped it with EAC) but this is not a good solution...

Thank you much.
Best Regards,

PS: Why is this reply 10000 characters wide (no word-wrap?)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2011-12-12 01:56:19
It's a known issue (http://www.cuetools.net/wiki/CTDB_EAC_Plugin#Known_issues) with the CTDB plug-in for EAC:

Quote
When copying selected tracks instead of an image, CTDB plugin doesn't process a CD if it has a HTOA (i.e. when first track does not start at 0:00:00).


Re: word wrap, it is being adversely affected by the "Additional command line options" line in your codebox. Not your fault.

Most info about CTDB, CUETools, CUERipper and the log files is only learned by reading third-party tutorials, having questions answered in forums, and just playing around with the software. It's on my to-do list to beef up the documentation in Gregory's wiki, and I did try to do that a little bit, but it's still in need of a lot of work. Feel free to register and lend a hand.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-12-12 02:39:53
Sorting stuff on my HDD I found this huuuge log ... I couldn't resist posting it  It's Iron Maiden - 2010 - The Final Frontier.

Code: [Select]
[CUETools log; Date: 11/12/11 22:36:36; Version: 2.1.2a]
[CTDB TOCID: qUrQvKCekqMe8BhgyPUESesZhRM-] found.
        [ CTDBID ] Status
        [2fd2ac1c] (7/8) Accurately ripped
        [56b88b51] (1/8) Differs in 1582 samples @03:28:50,03:54:50,04:00:50,04:06:22,04:14:49,04:18:50,04:37:08,04:38:40,04:38:58,04:39:36,05:07:24,
05:08:18,05:09:11,05:10:73,05:14:39,05:15:33,05:17:17,05:18:08,05:21:51,05:29:57,05:36:62,05:40:11,05
:43:06,05:52:18,06:14:39,06:18:05,06:22:49,06:23:42,06:27:12,06:28:04,06:28:71,06:35:12,06:37:30,06:4
0:42,06:42:27,06:44:27,06:57:46,07:02:02,07:13:18,07:49:37,07:53:40,08:02:66,08:03:58,08:09:72,08:18:
59,08:23:15,08:42:06,08:44:57-08:44:58,08:45:09,08:45:14,08:45:47,08:47:52,08:48:53-08:48:54,08:49:22,08:49:49,08:49:61,08:49:67-08:50:00,08:50:05-08:50:10,08:50:25,08:50:43,08:51:23,08:51:40,08:52:50,08:53:13,08:55:13,08:55:53,08:56:45,08:56:55,0
8:56:67,08:56:73,08:57:32,08:57:39,08:59:21,08:59:65,09:02:08,09:19:07,09:22:10,09:25:45,09:28:50,09:
29:04,09:29:48,09:30:35,09:33:19,09:34:34,09:35:18,09:36:05,09:36:34,09:37:48,09:38:17,09:39:73,09:42
:58,09:43:58,09:52:20,09:52:49,09:55:68,09:57:30,10:00:15,10:00:25,10:00:41,10:01:72,10:05:31-10:05:32,10:06:16,10:06:30,10:07:00,10:08:15,10:08:59,10:09:13,10:09:72,10:10:06,10:10:56,10:12:50-10:12:51,10:13:64,10:15:30,10:15:74,10:17:53,10:20:03,10:21:16,10:21:45,10:22:45,10:23:68,10:25:47,1
0:25:54,10:26:16,10:27:22,10:27:43,10:28:11,10:28:26,10:32:59,10:35:71,10:36:12,10:36:25,10:39:23,10:
41:17,10:42:72,10:43:42,10:45:43,10:46:28,10:47:41,10:49:24,10:49:53,10:50:51,10:51:06,10:53:32,10:53
:47,10:53:61,10:55:14,10:56:08-10:56:10,10:56:23,10:59:50,11:00:02,11:01:30,11:01:60,11:02:58-11:02:60,11:02:72,11:05:53,11:08:27,11:09:08,11:10:35,11:11:18,11:12:70,11:13:65,11:14:32,11:14:45-11:14:49,11:15:33,11:17:37,11:19:57-11:19:59,11:24:26-11:24:30,11:25:39,11:26:52,11:27:07,11:27:58,11:29:26,11:30:21,11:31:26,11:33:46,11:35:12,11:38:35,1
1:41:07,11:43:69,11:47:09,11:47:66,11:48:16,11:48:47,11:49:71,11:50:04,11:51:09,11:52:69,11:54:02-11:54:04,11:57:56,11:59:08,12:00:03,12:01:57,12:03:64,12:04:18,12:16:70,12:17:51,12:18:18,12:23:20,1
2:37:13,12:37:42,12:39:62,12:48:70,12:49:22,12:55:26,12:56:06,12:56:62,13:17:04,13:17:20,13:22:54,13:
29:56,13:30:10,13:35:06,13:38:42-13:38:43,13:46:67,13:51:04,13:51:31,13:56:14,13:57:35,14:02:26,14:03:06,14:04:71,14:08:22,14:09:16,1
4:10:68,14:15:18,14:19:67,14:31:72,14:34:57,14:37:54,14:42:12,15:00:15,15:22:53,16:55:70,17:11:05,17:
12:41,17:21:00,17:27:04,17:29:26,17:30:70,17:32:57,17:33:23,17:33:64,17:36:10,17:37:61,17:38:28,17:41
:18,17:44:05,17:56:02,17:56:46,17:57:53,18:00:02,18:05:12,18:05:63,18:08:30,18:08:51,18:08:62,18:09:3
7,18:09:43-18:09:47,18:13:59,18:14:48-18:14:49,18:19:19,18:21:30,18:22:66,18:24:25,18:25:13,18:27:64,18:28:29,18:32:11,18:33:57,18:35:31,1
8:36:56,18:42:39,18:45:05,18:46:41,18:49:01,18:54:35,18:59:29,19:09:39,19:18:68,19:19:34,19:20:00,19:
20:60,19:24:29,19:25:16,19:28:61,19:31:42,19:33:02,19:33:71-19:33:72,19:34:34,19:35:65,19:36:33,19:37:40,19:38:32,19:38:49,19:40:23,19:41:72,19:43:24,19:46:27,1
9:47:35,19:47:56,19:51:23,19:51:33,19:52:36,19:52:67,19:55:51,19:56:58,19:57:23,19:57:64,19:58:31,19:
59:37,20:00:45-20:00:46,20:01:21,20:04:72,20:06:02-20:06:03,20:06:44,20:07:10-20:07:11,20:08:17,20:08:47,20:09:12,20:09:40,20:11:15,20:13:51,20:16:71,20:25:37,20:26:50,20:33:59,2
0:38:17,20:39:68,20:41:42,20:46:20,20:51:14,21:26:53,21:54:01,21:56:45,21:59:46,22:12:11,22:13:39,22:
16:02,22:20:14,22:27:73,22:28:69,22:32:39,22:32:53,22:44:22,23:26:43,23:32:50,23:34:44,23:38:63,23:41
:04-23:41:05,23:43:09,23:44:06,23:46:25,23:49:67,23:51:00,24:08:50,24:14:46,24:26:59,24:34:62,25:01:31,2
5:05:57,25:10:73,25:18:07,25:19:61,25:21:24,25:22:62,25:23:15,25:24:24,25:25:04,25:26:36,25:31:58,25:
43:06,25:45:40,25:47:14,25:50:18,25:50:32,25:50:59,25:52:64,25:54:27,25:56:17,26:10:26,27:16:05,27:52
:41,28:00:74,28:07:37,28:08:62,28:09:33,28:10:40,28:11:53-28:11:55,28:12:50,28:22:56,28:43:70,28:44:51,29:19:53,29:23:73,29:41:37,29:45:03,30:25:52,30:33:37,3
0:39:39,30:44:73,30:46:60,30:50:00,30:55:44,30:55:71,30:58:67,31:00:37,31:01:67,32:55:59,34:10:42,34:
19:39,34:21:56,34:25:32,34:26:67,35:07:40,35:10:72,35:27:63,35:56:01,36:19:41,37:01:33,37:11:53,37:58
:05,38:00:52,38:27:68,39:12:46,39:13:26,39:13:52,39:39:17,39:41:37,39:41:62,40:03:45,40:06:52,40:09:0
5,40:09:27,40:10:27,41:24:56,41:27:03,41:28:46,41:37:00,41:40:31,41:44:16,41:46:08,41:47:53,41:48:55,
41:49:20-41:49:22,41:51:36-41:51:38,41:54:31,41:54:57,42:00:16,42:00:55,42:02:74,42:04:70-42:04:71,42:05:49,42:06:66,42:10:50,42:13:74-42:14:00,42:17:25-42:17:26,42:19:24,42:20:46,42:24:74,42:26:57-42:26:62,42:28:29,42:29:06,42:29:31,42:31:10-42:31:11,42:31:60,42:32:36,42:33:01-42:33:02,42:33:23,42:34:25,42:35:13,42:35:63-42:35:65,42:36:13,42:36:39,42:38:08-42:38:09,42:40:34,42:41:08,42:42:33-42:42:34,42:43:54,42:44:32,42:45:55,42:46:29-42:46:31,42:47:55,42:57:29,43:02:42,43:08:30,43:26:07,43:30:27,43:32:25,43:33:03-43:33:05,43:35:62,43:44:06,43:45:25,43:45:51,43:52:28,43:53:65,43:55:04-43:55:09,43:55:57-43:55:58,43:58:40,43:59:15,43:59:26,43:59:51-43:59:53,44:00:14,44:00:38-44:00:43,44:01:15,44:02:43,44:03:43,44:04:63,44:05:67,44:08:37,44:10:35,44:12:24,44:13:09,44:13:59,4
4:15:10,44:15:46-44:15:50,44:16:33,44:28:26,44:39:13,44:42:22,44:48:06,44:53:57,45:02:20,45:03:02,45:09:25,45:10:68,4
5:16:13,45:16:36,45:18:07,45:19:15,45:20:71,45:23:47-45:23:48,45:25:70,45:26:08,45:30:40,45:35:06,45:37:27,45:38:66,46:39:10,46:48:35,46:56:61,47:05:02,4
7:09:51,47:13:19,47:14:45-47:14:46,47:14:58,47:17:48,47:18:51,47:18:74,47:19:62,47:20:02,47:21:18,47:23:69,47:25:19,47:29:15,4
7:31:03,47:31:51,47:33:20,47:35:74,47:36:35,47:37:10-47:37:11,47:42:46,47:53:22,50:27:72,50:31:18,50:32:64,50:35:18,50:36:03,50:37:49,50:39:17,50:39:49,5
0:40:02,50:40:62-50:40:65,50:42:02,50:43:74,50:44:58,50:45:42,50:45:74,50:46:55,50:47:10,50:48:54,50:49:69,50:51:06,5
0:53:06,50:54:19,50:58:43,50:59:58,51:00:44,51:01:01,51:02:13,51:02:44,51:02:72,51:04:39,51:05:22,51:
06:06-51:06:07,51:07:51,51:08:62-51:08:64,51:09:16,51:10:00,51:12:21,51:13:07,51:13:65,51:15:33,51:17:02,51:17:61,51:19:17,51:20:11,5
1:21:27,51:21:53,51:22:24,51:24:03,51:24:62,51:25:32-51:25:33,51:26:01,51:28:00,51:28:58,51:28:63,51:29:41,51:31:10,51:31:68,51:32:23,51:32:52,51:32:67-51:32:68,51:34:18,51:35:23,51:35:61,51:36:63,51:37:30,51:38:15,51:38:72,51:40:17,51:40:41,51:41:56,5
1:42:08-51:42:09,51:42:68,51:44:35,51:44:65,51:45:18,51:46:02-51:46:03,51:47:43,51:47:54,51:48:47,51:48:53,51:49:07,51:49:38,51:49:66,51:50:49,51:51:31,51:52:13,5
1:53:51,51:55:72,51:56:55,51:57:37,51:57:66,51:59:00-51:59:01,51:59:57,52:00:09,52:00:30,52:02:02,52:02:53,52:05:16,52:06:56,52:08:24,52:10:47,52:12:72,5
2:14:41,52:16:23,52:17:47,52:19:11-52:19:12,52:21:35,52:22:33,52:22:61,52:24:24,52:24:39,52:28:00,52:28:27,52:29:40-52:29:42,52:32:15,52:32:71,52:35:46,52:35:73,52:36:14,52:36:24,52:37:37,52:38:74,52:39:56,52:42:59,5
2:43:41,52:44:22,52:45:05-52:45:06,52:45:62,52:48:07,52:48:64,52:50:24,52:51:21,52:52:62,52:54:29,52:54:71,52:57:31,52:57:74,5
2:58:71,52:59:69,53:00:20,53:00:35,53:01:29,53:01:56,53:05:39,53:07:00,53:07:55,53:08:37,53:10:00-53:10:01,53:11:38,53:11:67,53:12:18,53:13:53,53:14:35,53:17:33,53:22:20,53:24:60-53:24:61,53:25:52-53:25:54,53:27:32-53:27:33,53:28:16,53:29:22,53:30:19,53:30:63,53:31:58,53:33:20-53:33:21,53:34:56,53:36:61,53:37:54,53:39:01,53:41:19,53:42:55,53:43:34,53:44:14,53:44:70,53:46:05,5
3:47:11,53:47:32,53:48:46,53:52:23,53:53:03,53:55:71,53:59:21,54:00:01,54:00:27,54:01:08,54:01:60,54:
03:37,54:04:27,54:07:23,54:08:47,54:09:62,54:13:62,54:14:31,54:15:74,54:17:30,54:18:63,54:20:22,54:23
:12,54:24:40,54:27:12,54:33:59,54:35:17,54:38:08,54:38:63,54:39:42-54:39:43,54:40:21,54:40:74,54:43:11,54:43:65,54:46:00,54:46:53,54:48:41,54:49:17,54:53:35,54:59:00,5
5:00:29,55:04:47,55:06:35,55:09:34,55:10:14,55:13:72,55:19:67,55:22:08,55:27:20,55:28:55,55:34:00,55:
37:58,55:38:39,55:40:00,55:44:53,55:45:22,55:46:17,55:46:60,55:47:54,55:50:36,55:51:16,55:56:04,55:56
:31,55:57:13,55:59:27,56:01:01,56:01:41,56:03:49,56:05:62,56:11:03,56:11:44,56:22:05,56:24:35,56:28:0
1,56:28:56,56:31:48,56:32:25,56:33:04,56:35:16,56:38:02,56:42:23,56:43:01,56:44:32,56:50:11,56:51:45,
56:52:23,57:00:20,57:00:73,57:05:03,59:47:36,60:06:55,60:09:71,60:20:53,60:25:42,60:27:14,60:47:71,60
:56:26-60:56:27,61:01:27,61:01:63,61:03:61,61:03:74,61:04:51,61:06:53,61:10:53,61:11:24,61:14:51,61:22:37,6
1:49:43,62:07:22,62:11:04,62:13:14,62:24:62,62:35:73,62:40:14,62:42:31,62:45:54,62:50:71,62:59:47,63:
06:59,63:13:00,63:18:43,63:27:19,63:43:45,63:50:72,63:51:46,63:53:48,64:00:29,64:01:03,64:01:53,64:02
:41,64:02:68,64:05:42,64:07:55,64:08:13,64:08:29,64:09:04,64:09:66,64:10:27,64:10:40-64:10:41,64:11:26,64:18:16,64:22:21,64:22:35,64:23:23,64:29:23-64:29:24,64:29:60,64:30:35,64:31:10,64:31:70-64:31:71,64:32:32,64:33:19-64:33:20,64:58:37,65:10:39,65:15:61,65:16:27,65:19:45,65:25:44,67:52:13,68:22:72,68:27:04,68:32:45,6
8:33:10,68:34:48,68:36:49,68:38:12,69:26:54,69:45:62,69:57:69,70:14:56,70:15:72,70:20:27,70:25:38,70:
27:31,70:27:54,70:34:29,70:38:62,70:44:61,70:52:50,70:53:22,70:55:60,71:01:69,71:02:55,71:03:15,71:06
:33,71:18:70,71:19:41,71:45:42,71:56:27,71:59:31,72:01:43,72:11:24,72:19:64,72:21:10,72:26:48,72:56:5
1,73:26:14,73:35:74,73:54:37,74:04:39-74:04:40,74:08:60,74:16:34,74:44:45,74:45:22,74:46:25,74:47:30,74:48:63,74:52:28
[AccurateRip ID: 001ad3a9-00d82b34-8911f60a] found.
Track  [ CRC    ] Status
 01    [4bbc4d50] (005/216) Accurately ripped
 02    [f25786ab] (005/216) Accurately ripped
 03    [97baf0f5] (005/219) Accurately ripped
 04    [61914777] (004/217) Accurately ripped
 05    [3b7444dc] (004/217) Accurately ripped
 06    [74a56f5c] (004/215) Accurately ripped
 07    [6d565c22] (004/217) Accurately ripped
 08    [0ad94419] (004/217) Accurately ripped
 09    [bb396870] (003/214) Accurately ripped
 10    [7b3de080] (004/214) Accurately ripped
Offsetted by 19:
 01    [9b8654e5] (146/216) Accurately ripped
 02    [39ca0056] (148/216) Accurately ripped
 03    [c45c9420] (149/219) Accurately ripped
 04    [e92e5920] (149/217) Accurately ripped
 05    [e0d3fb82] (149/217) Accurately ripped
 06    [e4b427d0] (149/215) Accurately ripped
 07    [5f59da47] (149/217) Accurately ripped
 08    [e97eb561] (149/217) Accurately ripped
 09    [b5513330] (147/214) Accurately ripped
 10    [d1ad382b] (146/214) Accurately ripped
Offsetted by 25:
 01    [41476abf] (039/216) Accurately ripped
 02    [8fb5f386] (039/216) Accurately ripped
 03    [d4b5e8d6] (039/219) Accurately ripped
 04    [eabd64d4] (038/217) Accurately ripped
 05    [fb5cce76] (040/217) Accurately ripped
 06    [dec9d720] (038/215) Accurately ripped
 07    [e1f1e44f] (038/217) Accurately ripped
 08    [5dfcb992] (038/217) Accurately ripped
 09    [4996aca4] (038/214) Accurately ripped
 10    [557cfaf6] (038/214) Accurately ripped
Offsetted by 1:
 01    [b237dd3d] (002/216) Accurately ripped
 02    [0eff8c46] (000/216) No match
 03    [c9c4a85a] (002/219) Accurately ripped
 04    [9030c7e9] (002/217) Accurately ripped
 05    [6cba691a] (000/217) No match
 06    [e99b5c78] (000/215) No match but offset
 07    [e5027213] (002/217) Accurately ripped
 08    [255745b7] (002/217) Accurately ripped
 09    [f877c6cf] (002/214) Accurately ripped
 10    [cfe775cc] (002/214) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100,0 [88B62A44] [E6A2450B]  CRC32 
 01  100,0 [88DB9127] [3F9BFE55]         
 02  100,0 [6304AE32] [05C232FC]         
 03  100,0 [3C640803] [414C3EA4]         
 04  100,0 [CA556664] [3DD68C85]         
 05  100,0 [9A9F48CF] [7A6AF916]         
 06  100,0 [88108C86] [F767304D]         
 07  100,0 [72450FED] [4C3D2B60]         
 08  100,0 [0ECE4025] [874490CB]         
 09  100,0 [DC06AF9F] [0B960262]         
 10  100,0 [A4604796] [2784E74D]   
     
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-13 00:37:16
Ah, I should've re-checked that wiki; I do have it opened in one of the tabs in browser, but never thought to click on the plugin page (right now I'm trying to get thru this thread; I'm at page 32 right now). There's a lot of information to absorb.

Well then for now I guess I'll just use CueRipper to submit (CueTools is supposed to ask to submit at some point, there is a setting for this in advanced, but I haven't figured out how to get it to submit yet).

Thanks again for the information.
Best Regards,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-12-13 03:18:13
CueTools is supposed to ask to submit at some point, there is a setting for this in advanced, but I haven't figured out how to get it to submit yet
Action: Verify will do it but only if AccurateRip confidence is 2+ and there is no current matching CTDB entry. You cannot add to an existing CTDB entry using Verify. Of course Submit to CTDB has to be True under Advanced. I apologize for being terse earlier.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-15 05:45:53
Good evening Korth.

I'm at page 46 of this thread, slowly moving forward.

I've been ripping more CDs and I find that CueRipper is WAY better than EAC when it comes to bad pressings. Where EAC detects 5-20 (yes, 20) "Suspicious" positions for some tracks and fails AR test, CueRipper detects 1 such position (or none) and passes AR test. I will post more about this later, but lets just say it is far better at error recovery than EAC (even with the 5*16 re-reads). CR is also much faster.

About submitting with CueTools:

I can't get it to submit; here is a verify which has a total confidence of 4, yet CueTools is not asking for submit (and yes, it's turned on in advanced settings):

Code: [Select]
[CUETools log; Date: 2011-12-15 00:32:52; Version: 2.1.2a]
Pregap length 00:00:32.
[CTDB TOCID: aZdHKV0MXmQGVnILK0gQMr5Xytk-] disk not present in database.
[AccurateRip ID: 00081a88-002b8b53-46085e06] found.
Track  [ CRC    ] Status
 01    [84595bf2] (2/6) Accurately ripped
 02    [f801ab27] (2/6) Accurately ripped
 03    [19ce2654] (2/6) Accurately ripped
 04    [57eb60f1] (2/6) Accurately ripped
 05    [f9360dff] (2/6) Accurately ripped
 06    [557ae3b4] (2/6) Accurately ripped
Offsetted by 736:
 01    [39fe3b12] (2/6) Accurately ripped
 02    [2b7a8607] (2/6) Accurately ripped
 03    [608b7354] (2/6) Accurately ripped
 04    [411ad9d1] (2/6) Accurately ripped
 05    [3727b09f] (2/6) Accurately ripped
 06    [67d86dba] (2/6) Accurately ripped
Offsetted by 816:
 01    [a6c7cdc2] (0/6) No match but offset
 02    [b112ca57] (0/6) No match but offset
 03    [89a006d4] (0/6) No match but offset
 04    [54e2cb21] (0/6) No match but offset
 05    [bde3588f] (0/6) No match but offset
 06    [def9a21d] (0/6) No match but offset

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  89.6 [1B2B1222] [50BA4722]         
 01  82.1 [F57FE8CA] [223180AE]  CRC32 
 02  89.6 [DA634237] [554CECE9]  CRC32 
 03  85.9 [B1A48338] [4E59B2DF]  CRC32 
 04  78.6 [119B0E77] [3F293967]  CRC32 
 05  82.7 [DA443803] [6BAC3CF0]  CRC32 
 06  89.6 [1E6ABF03] [C797114A]  CRC32 
Am I mis-understanding something?

Thank you much.
Best Regards,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-12-15 06:02:38
If I recall well CT will only submit if "Verify/Default" is used not "Verify/Only If Found". Maybe you're using "Verify/Only If Found".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-16 00:58:32
WooHoo, Success!

Merci beaucoup Sauvage, c'etait ca! I needed to verify at default. I dont need "Only If Found" anyway, I rip CDs one at a time and verify the rip immediately afterwards - i.e. I never batch verify anything. I think CT just defaulted to selecting that mode and I never dared touch it.

I guess it makes sense; you dont want the submit pop-up to show when you are verifying a thousand songs...

Best Regards,

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-16 02:34:50
Ah, found it! page 49 of the thread:
Only-If-Verify will not submit (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=760834)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-16 04:28:47
The slider on the right is the ripping method. Secure means that the track is is read twice and the checksums are compared to see if the rip is clean. Paranoid mode will rip the track 4 times and compare the checksums of each rip to make sure they match.

That does not seem entirely accurate; when I rip in paranoid mode I see "Ripping@..." once, then Retry 1 and Retry 2; no Retry 3... So I would say Paranoid reads 3 times (on sectors that have no errors). Paranoid might allow more retries than secure when there -are- errors, I haven't tried yet.

Code: [Select]
CUERipper v2.1.2 Copyright (C) 2008-10 Gregory S. Chudov
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Usage    : CUERipper.exe <options>

-S, --secure             secure mode, read each block twice (default);
-B, --burst              burst (1 pass) mode;
-P, --paranoid           maximum level of error correction;

Regards,

PS: Anyone know how to make CueRipper start in Paranoid mode? It resets to secure everytime I start it. I tried SecureMode=2 -> Ng; Tried ParanoidMode=1 but no go either. I don't think it has the ability to retain Paranoid in its settings file...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-12-16 18:51:49
I don't think it has the ability to retain Paranoid in its settings file...
SecureMode=2 would be the correct setting but CUERipper does not start in Paranoid mode. Why would you even want to use this mode on anything other than a badly scratched or scuffed disc? Secure mode will read each sector a minimum of 2 times and up to 32 times if the reads don't match.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-12-16 23:51:07
A feature that I would like to be in CT is the ability to check & update .accurip against the database in order to check lossy encoded files for which you know the lossless ID/CRC.

Exemple:
1- Rip a CD losslessly then check against AR/CTDB database, unfortunately the CD is not in database either because it is rare or new.
2- Unfortunately you don't have the HDD space to store it losslessly, so you encode it lossyly.
3- Happily as you have checked it when it was lossless you still have all the ID & CRC necessary to re-check later even without having the lossless data anymore.
4- With this new feature, update the lossless .accurip in order to verify if the rip is now in database & if it was really accurate.

Indeed if it's not accurate you cannot repair as it's lossy now, still it would be interesting to be able to verify afterward that a lossy rip was accurate before being encoded.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-17 00:29:34
Hey Gorth!

I dont mind Paranoid, I have several CDs in perfect condition (not a scratch, not a smudge, nothing) where both EAC and CueRipper read tons of errors (EAC took 12 hours to rip one of those and reported 20+ suspicious positions on 2 tracks; CueRipper ripped it in an hour and it passed AR, but the RED bar was always almost maxed). You become paranoid when this happens on several otherwise pristine CDs. I'd use CueRipper always, if it could do a few things more (external compressor with tags passed on command line, drop-box for album art, database, ...)

It's on one of those CDs that I had to re-rip with CueRipper that I noticed significant differences in PREGAP displayed in EAC/Cue logiles.

Look at this, same CD ripped with both programs:

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011
CUERipper v2.1.2 Copyright (C) 2008-10 Gregory S. Chudov

Rush / Moving Pictures

Used drive  : PIONEER DVD-RW  DVR-116D   Adapter: 0  ID: 1

     Track |   Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.32 |  4:37.08 |        32    |    20814  
        2  |  4:37.40 |  6:10.70 |     20815    |    48634  
        3  | 10:48.35 |  4:26.00 |     48635    |    68584  
        4  | 15:14.35 |  4:21.35 |     68585    |    88194  
        5  | 19:35.70 | 11:00.00 |     88195    |   137694  
        6  | 30:35.70 |  4:45.52 |    137695    |   159121  
        7  | 35:21.47 |  4:46.73 |    159122    |   180644  

Track 1  EAC= Pre-gap length 0:00:02.32  CueRipper= Pre-gap length 0:00:02.42
Track 2  EAC= Pre-gap length 0:00:03.28  CueRipper= Pre-gap length 0:00:03.37
Track 3  EAC= Pre-gap length 0:00:00.68  CueRipper= Pre-gap length 0:00:00.90
Track 4  EAC= Pre-gap length 0:00:00.55  CueRipper= Pre-gap length 0:00:00.73
Track 5  EAC= Pre-gap length 0:00:01.04  CueRipper= Pre-gap length 0:00:01.05
Track 6  EAC= Pre-gap length 0:00:00.68  CueRipper= Pre-gap length 0:00:00.90
Track 7  EAC= Pre-gap length 0:00:01.47  CueRipper= Pre-gap length 0:00:01.62

Is there something wrong with CueRipper's gap detection?

Gregory:
Your database now contains almost all of the Rush albums; now that you're here (Canada) you're gonna have to start listening to Rush ;-) And if you end-up ripping your shiny new Rush CDs, you'll have an entry to compare against :-) You're in Ottawa right? If you're looking for a decent rock radio station, try 97.7fm; it's in Montreal but it might reach ya. They don't play enough Floyd, but they do play a lot of Rush, lol.

Thanks.
Best Regards,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: B00ze on 2011-12-17 19:47:07
I've just had CueRipper reach retry#61 on a rip before the red bar disappeared.
If Paranoid mode doubles the retries (32->64) I'd say it's worth it on some rips.
L8r,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: JeanV on 2011-12-19 02:20:37
Hi,

How can I split the image with this cue sheet?

Code: [Select]
TRACK 01 AUDIO
    TITLE "Man's Best Friend"
    PERFORMER "Clark Hutchinson"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Love Is The Light"
    PERFORMER "Clark Hutchinson"
    INDEX 01 05:50:40
  TRACK 03 AUDIO
    TITLE "The Light Burns On"
    PERFORMER "Clark Hutchinson"
    INDEX 00 05:51:04
    INDEX 01 11:48:23
  TRACK 04 AUDIO
    TITLE "Come Up Here"
    PERFORMER "Clark Hutchinson"
    INDEX 00 05:51:14
    INDEX 01 14:23:48
  TRACK 05 AUDIO
    TITLE "Disorentared. Part One."
    PERFORMER "Clark Hutchinson"
    INDEX 00 05:51:31
    INDEX 01 17:22:02
  TRACK 06 AUDIO
    TITLE "Boat In The Morning Mist"
    PERFORMER "Clark Hutchinson"
    INDEX 00 05:51:62
    INDEX 01 19:12:17
  TRACK 07 AUDIO
    TITLE "Oroented"
    PERFORMER "Clark Hutchinson"
    INDEX 00 05:52:42
    INDEX 01 23:49:35
  TRACK 08 AUDIO
    TITLE "First Reminder"
    PERFORMER "Clark Hutchinson"
    INDEX 00 05:52:73
    INDEX 01 25:35:36
  TRACK 09 AUDIO
    TITLE "Mix Elixir"
    PERFORMER "Clark Hutchinson"
    INDEX 00 06:20:67
    INDEX 01 30:54:35
  TRACK 10 AUDIO
    TITLE "Poison"
    PERFORMER "Clark Hutchinson"
    INDEX 00 09:21:01
    INDEX 01 33:54:45
  TRACK 11 AUDIO
    TITLE "Disoientated Part Two (As)"
    PERFORMER "Clark Hutchinson"
    INDEX 00 13:35:66
    INDEX 01 38:09:18

The gaps look very odd, and I get this error: 'Exception: Indexes must be in chronological order' error.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2011-12-19 06:26:32
JeanV, you need to use codebox tags when posting logs, etc., so they appear in a scrollable section. Too late now.

What did you use to generate that cue sheet? Or did you just "find" it somewhere? It's damaged beyond repair.

The timestamp after each INDEX ## is supposed to be a position (minutes:seconds:frames format) within most recently mentioned audio FILE (or whichever file you're forcing the cue sheet to be used with). So track 10 index 01 begins at 33:54:45 and track 11 index 01 begins at 38:09:18 ... probably correct. But this means it is nonsensical for track 11 index 00, which is in between, to be at 13:35:66. The story is the same for all the other index 00s.

For splitting, you really only need the index 01s (because you're splitting on track boundaries, and for this disc there's no track 01 index 00 to worry about). So to "fix" the cue sheet, you could delete the INDEX 00 lines, and then it should "work". It no longer represents the original CD, but in this case, that's not a change from the status quo. It didn't represent the original CD properly anyway

If you were to use the cue sheet with the index 00s deleted to burn a copy, the resulting CD-R will be mastered with no 'gaps' (places where you see the cd player count from a negative time up to 0:00 at the end of each track). The audio and the main track boundaries will be OK.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2011-12-19 10:42:58
Wow that's a lot of questions. You couldn't find the answers somewhere in the other 67 pages?


67 pages, that's a lot ... I would rather advise users to go to http://www.cuetools.net/wiki/ (http://www.cuetools.net/wiki/) 

(And then perform a couple of searches, and then ask.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-12-19 12:03:25
I would rather advise users to go to http://www.cuetools.net/wiki/ (http://www.cuetools.net/wiki/)  (And then perform a couple of searches, and then ask.)
I had assumed B00ze would use the search feature to look up answers to specific questions as I did in the example.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2011-12-19 13:14:16
How can I split the image with this cue sheet?
[snip]
The gaps look very odd, and I get this error: 'Exception: Indexes must be in chronological order' error.


JeanV, you need to use codebox tags when posting logs, etc., so they appear in a scrollable section. Too late now.
It’s never too late!  I agree with your conclusions that the INDEX 00 values are nonsensical, so they should just be removed, which won’t affect splitting or the audio itself anyway.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: JeanV on 2011-12-19 14:40:26
JeanV, you need to use codebox tags when posting logs, etc., so they appear in a scrollable section. Too late now.

What did you use to generate that cue sheet? Or did you just "find" it somewhere? It's damaged beyond repair.

The timestamp after each INDEX ## is supposed to be a position (minutes:seconds:frames format) within most recently mentioned audio FILE (or whichever file you're forcing the cue sheet to be used with). So track 10 index 01 begins at 33:54:45 and track 11 index 01 begins at 38:09:18 ... probably correct. But this means it is nonsensical for track 11 index 00, which is in between, to be at 13:35:66. The story is the same for all the other index 00s.

For splitting, you really only need the index 01s (because you're splitting on track boundaries, and for this disc there's no track 01 index 00 to worry about). So to "fix" the cue sheet, you could delete the INDEX 00 lines, and then it should "work". It no longer represents the original CD, but in this case, that's not a change from the status quo. It didn't represent the original CD properly anyway

If you were to use the cue sheet with the index 00s deleted to burn a copy, the resulting CD-R will be mastered with no 'gaps' (places where you see the cd player count from a negative time up to 0:00 at the end of each track). The audio and the main track boundaries will be OK.



It’s never too late!  I agree with your conclusions that the INDEX 00 values are nonsensical, so they should just be removed, which won’t affect splitting or the audio itself anyway.


Many thanks, mjb2006 and db1989, sorry for missing the codebox tag.

I also thought that deleting the INDEX 00 lines might be the only way to go, but then found these two posts (#140 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=607130) - #142 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=607167)) in the forums, which suggest changing the Gap/Index retrieval method (and I don't know what that is) might fix the gaps. Could the cue sheet be rectified doing so?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2011-12-19 14:44:30
There’s only one way to find out.  It’s certainly a possibility. Maybe we should’ve thought of that!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2011-12-19 16:21:35
I also thought that deleting the INDEX 00 lines might be the only way to go, but then found these two posts (#140 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=607130) - #142 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=607167)) in the forums, which suggest changing the Gap/Index retrieval method (and I don't know what that is) might fix the gaps. Could the cue sheet be rectified doing so?
In EAC (http://exactaudiocopy.de/), having the wrong Gap/Index retrieval method (http://blowfish.be/eac/Setup/setup5.html#no5d) can result in "strange" gaps. You didn't specify how your cue was created. Post(s) #139-142 are referring to a cue created using EAC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: JeanV on 2011-12-19 17:46:03
In EAC (http://exactaudiocopy.de/), having the wrong Gap/Index retrieval method (http://blowfish.be/eac/Setup/setup5.html#no5d) can result in "strange" gaps. You didn't specify how your cue was created. Post(s) #139-142 are referring to a cue created using EAC.


Ah, so that's got to do with EAC and how the rip was done beforehand. Now, deleting the INDEX 00 lines is the best bet for me. Thank you. :-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d3m0n1q_733rz on 2011-12-22 03:04:35
I've happened upon a bit of a small (though pretty resource intensive) bug that causes CueTools 2.1.2a to keep the takc encoder open when changing an offset fails.  I had an offset that I was attempting to change to a positive number when it said there was an error with the stream not allowing seeking.  After the failure, the takc.exe program was left running and still attempting to encode.  I ended up with 8 of them slowing down my computer before I finally decided to investigate what was being so resource intensive.  So you might want to fix this bug in 2.1.2b.  I'm also looking for a way to fix some problems with multiple offsets due to sync errors from other programs.  I have different songs come up as being accurate with some offsets (-24) and others coming up as no match found.  Is it possible to change the software to base the matches of the unmatched songs upon the accurate results of the songs around them so as to increase recovery of extremely poor rips?
For example, if an offset of -24 results in the greatest number of accurate rip results for most songs, it won't necessarily mean it for all songs so matching the results with samples will be difficult.  However, if we allow multiple different offsets (different for each song), it will increase the chance of a repair due to sync errors.  So, is it unheard of to so such a thing?  I would like to make repairs as simple, automated and intelligent as possible.  Unfortunately, this means shifting tracks around (filling the shifts with 0s and making them mostly bad samples) until they mostly fit the CRC and then replacing the bad samples afterward to complete the repair.

Let me know what you think!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2011-12-24 16:37:47
Windows 7 Home Premium 64-bit
CueTools 2.1.2a

Hi:

I normally use CueTools in Drag 'n' Drop Mode. One of the reasons is i like the wide window which more easily shows the results and summary line after a Verify operation.

I created  Windows "Send To" shortcut so I can right-click a .cue sheet to have it automatically open in CueTools, ready to Verify. However, when CueTools launches this way, it is not in Drag 'n' Drop Mode, ut is instead a tall, narrow window that seems to be Hide Browser mode. I am unable to make that window wider, which makes it awkward to ready Verify results.

1. How can I have CueTools always launch into my preferrred Drag 'n' Drop Mode, even when it launches by a file being sent to it via a Send To shortcut? Are there settings I can change to do this, or some command string or batch file that could launch CueTools with some switches or parameters?

Drag 'n' Drop Mode shows a nice summary of the Verify, e.g. AR: rip accurate (41/41), CTDB: verified OK, confidence 41, but does not show the full .accurip results in the CueTools window. Other modes show full full .accurip results but do not include the nice summary statement.
2. Is there a way to have CueTools display both the summary line and the full results after a Verify?



Thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: kotekzot on 2011-12-26 16:12:00
Hi, I have a couple of rips that CUETools has to do offset correction on to verify against AccurateRip DB. Is there any way to permanently "fix" them, or has the necessary data been lost due to poor ripping?

Also, if a dummy cue sheet passes AR validation, can it be considered exact?

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2011-12-26 16:56:15
kotekzot:

1: Use Encode\Fix Offset. Default is "fix to nearest". You can change it "fix to highest" in the options.
Nothing is lost as offsets doesn't matter, the only thing you may have lost is the knowledge of which offset was the original one of your CD, but it doesn't really matter as all those pressings that only differs by an offset are equivalent.

Edit: You can also fix them manually one by one if you know exactly which offset you wanna match, just enter the wanted offset in the front offset box & encode. It will be sharper but much longer as nothing will be automatic then.

2: The splitpoints aka INDEX 01 in a CDImage.cue (or Tracks length if you prefer) are correct. Other info of various importance that a CUE can contain are missing.

No new CT version for Christmas ... blah ;(
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d3m0n1q_733rz on 2011-12-27 19:16:12
Another bug found!  Most recent version of CueRipper errors when you click the track length of a data track.  Unhandled exception.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2012-01-01 07:01:44
Hey guys, I just downloaded a flac file I verified with CT (as always) which turned out to be a "no match but offset" one. 

Code: [Select]
[CUETools log; Date: 22/12/2011 1:43:39; Version: 2.1.2a]
[CTDB TOCID: q.J5giMFoJd0kQr3cHgcHLEkh7s-] disk not present in database.
[AccurateRip ID: 000fed5b-006fb89e-6e098309] found.
Track  [ CRC    ] Status
 01    [de1e3119] (0/1) No match
 02    [03693299] (0/1) No match
 03    [062b2a55] (0/1) No match
 04    [9504aee9] (0/1) No match
 05    [af53be68] (0/1) No match
 06    [9e7138e5] (0/1) No match
 07    [55dd40f2] (0/1) No match
 08    [7065ff8a] (0/1) No match
 09    [0aead0ac] (0/1) No match
Offsetted by -24:
 01    [ae80cc09] (0/1) No match but offset
 02    [87947cc1] (0/1) No match but offset
 03    [20946c45] (0/1) No match but offset
 04    [ea57ba99] (0/1) No match but offset
 05    [69917058] (0/1) No match but offset
 06    [55f7c0dd] (0/1) No match but offset
 07    [142944ea] (0/1) No match but offset
 08    [2e5f2af2] (0/1) No match but offset
 09    [1396e04c] (0/1) No match but offset

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100,0 [93962B01] [47181DCC]  CRC32 
 01  96,6 [C19C5852] [9A9B82D7]         
 02  100,0 [5AB35513] [7237144A]         
 03  98,0 [D3545233] [02FF9787]         
 04  98,3 [1F1F7C47] [489EB4AE]         
 05  97,9 [F6A1F5E0] [C9E2C524]         
 06  98,2 [7A2F2D39] [20D741B3]         
 07  97,2 [012EE406] [65418D67]         
 08  95,8 [A497CE45] [E95C3C68]         
 09  97,2 [CA6013F4] [1705EC9C]         

Well, I ended up burning anyways, offset-correcting in the meantime.
With this my "brand new" CD I repeated the process of ripping & verifying, BUT... now it turned out to be "accurately ripped".

Code: [Select]
[CUETools log; Date: 01/01/2012 3:10:10; Version: 2.1.2a]
[CTDB TOCID: q.J5giMFoJd0kQr3cHgcHLEkh7s-] disk not present in database.
[AccurateRip ID: 000fed5b-006fb89e-6e098309] found.
Track  [ CRC    ] Status
 01    [ae80cc09] (0/1) No match but offset
 02    [87947cc1] (0/1) No match but offset
 03    [20946c45] (0/1) No match but offset
 04    [ea57ba99] (0/1) No match but offset
 05    [69917058] (0/1) No match but offset
 06    [55f7c0dd] (0/1) No match but offset
 07    [142944ea] (0/1) No match but offset
 08    [2e5f2af2] (0/1) No match but offset
 09    [1396e04c] (0/1) No match but offset
AccurateRip v2:
 01    [cff94e79] (1/1) Accurately ripped
 02    [9d16df24] (1/1) Accurately ripped
 03    [3d30d8f8] (1/1) Accurately ripped
 04    [08b4a99a] (1/1) Accurately ripped
 05    [df62cb36] (1/1) Accurately ripped
 06    [77080667] (1/1) Accurately ripped
 07    [9a55ed90] (1/1) Accurately ripped
 08    [34e7f011] (1/1) Accurately ripped
 09    [40d8ff09] (1/1) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100,0 [D079E009] [47181DCC]  CRC32 
 01  96,6 [4D444A54] [9A9B82D7]         
 02  100,0 [D843C366] [7237144A]         
 03  98,0 [F3E83C36] [02FF9787]         
 04  98,3 [6F92B98A] [489EB4AE]         
 05  97,9 [497DC845] [C9E2C524]         
 06  98,2 [365EF879] [20D741B3]         
 07  97,2 [11BFDF1F] [65418D67]         
 08  95,8 [C3D27F4A] [E95C3C68]         
 09  97,2 [C0B98852] [1705EC9C]         

Can someone tell me why doesn't CT warn of this ARv2 match for the offset(-24) instead of stating this misleading message.
I've been discarding all those "no match but offset" since long ago taking them for bad rips, and now I suddenly come across they were all probably good. 

Thanks in advance!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2012-01-01 10:16:33
First, it's not nice to talk about verifying illegal downloads in this thread, CueTools was not designed for that purpose. Second, AR2 verification does not perform offset checking. There was a debate between Spoon and Gregory a few months ago in this thread, and Gregory said that AR2 verification across pressings is too time consuming or something, so it's not implemented (yet?).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2012-01-01 11:30:29
Actually CT only display ARv2 results on the actual offset, I think displaying ARv2 results on other offsets is planned for a future version.
The actual way of displaying was thought for ARv1, actually displaying ARv2 is more a quick "hack" than anything else.
The full support of ARv2 is on the TODO list, but I agree it is taking too much time, according to me there are several reasons for this:
1- There was a disagreement between Spoon & Gregory about the usefullness of ARv2, now Gregory is more or less "forced" to support something he didn't asked for (as time goes by, I tend to agree with Gregory personnaly)
2- With full ARv2 support the displaying of log might completely change as Gregory posted an idea of horizontal log displaying in order to avoid very long vertical logs, reinventing the wheel might take longer than expected.
3- I suspect Gregory is more or less willing to make CTDB independent from AR as I suspect that despite his diplomatic behavior he didn't appreciated that much how ARv2 was implemented without his help. Gregory already stated that there is no CRC that AR stores & that CTDB doesn't store anymore. In the beginning CTDB was AR dependent, because both were using different CRC (tracks vs image) if I recall correctly. (Don't slam me if I am wrong Greynol !)
4- The introduction of the CTDB plugin for EAC makes the future of CT even harder to read, as it seems very efficient in term of submissions (even bad ones). Will there be a CTDB plugin for dBpoweramp in order to have a single database for all rippers dBpoweramp/Cueripper/EAC ??? I doubt Spoon would like the idea much ... will Gregory work with EAC more closely ? no one knows.
5- Gregory just get married & is currently cheating his computer. Full ARv2 support would certainly be faster if he would have wed Spoon. (Just Kidding Spoon !)

Anyway it would be great If Gregory could clear the future of the CTDB for 2012. I mean we all see what should be fixed or improved in CT, but actually we are at a point where any further CT development is dependent on how Spoon/Gregory/Andree are willing ... or not willing ... to work together on an harmonized verification\correction database.

As an end user, the way I see it: there is Spoon on one side & Gregory & Andree on the other, because Spoon already has his baby [AR which is GREAT, no discussion] & because Spoon sells software [which means he wants to keep control of his business which is natural]. Furthermore the recent past (ARv2) has shown that Gregory & Spoon didn't work that well together. As far as I understood both have respect for each other works as developpers, but none (well to be honest specially Spoon IMHO) is willing to let the other introduce himself in his own business. It is likely that Spoon invested too much time in AR development to drop it in favor of a cross-ripper improved CTDB platform. Furthermore is Gregory really wiling to achieve the development & manage such a platform ?  For me there are hints that shows we tend toward this, but the fact that there is actually no futher CT visible development is also an hint that Gregory has a lot of hesitation himself ... because with or without the help of Spoon & Andree ... it's likely a lot of work.

Be warned, some of the above might be complete bullshits due to high speculation  It's new year day & maybe I'm still drunk. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2012-01-01 12:01:47
ARv2 was a simple fix to a flaw, it required about 10 minutes of programming effort to implement in a program which already uses ARv1. Despite all the talk about how CRC32 should have been used, I have never seen a false positive from AR, also ARv1 CRC is there also, so potentially you have 64 bits of CRC!

I have always said, for a program to state is compatible with ARv2 it should use the offset CRCs to check across pressings, this is efficient (typically a CD will have 4 offsets which need checking), after all we are not computing the next unknown prime number, just simple CRCs on audio.

AccurateRip is being worked on to allow the ~99.99999% of people who do not use a secure ripper to be able to verify their rips, and possibly correct bad rips, whilst being able to work on single files. I am sure I am not alone when I rip an album, listen to the tracks I like and delete the ones I do not like.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2012-01-01 12:23:14
The biggest problem with CT not fully supporting ARv2 is that ARv1 submissions has more or less stopped (didn't hunt to verify if it's completely stopped), so with recent CD (post ARv2 introduction), ARv2 is often more populated than ARv1 ... & with CT not fully supporting ARv2 you don't see the whole picture of submissions anymore. If you don't fix offset while ripping, with a "post ARv2 introduction" new CD ... you may completely miss the submissions as those will be invisible.

It's also a problem when "fixing to highest" offset in database, nowadays I am unable to guess if it's already "fixed to highest" as I miss "half" (exagerating but sooner or later it will be half) of the submissions, & I am sure that it introduces other missbehaviors with other uses of CT than mine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2012-01-01 19:53:28
All clearer now thanks to your replies, sauvage78 & spoon.
I'm not an everyday forum visitor (cause I have to take care of my own "illegal" forum  ), so I didn't know it already was in a TODO list. Hope it soon get implemented in a vertical log display way (preferably) so we can catch the full picture.  It would be of great use for fighting people's laziness who tends to do untidy works, sometimes not even correcting their drives' offsets... or what's worse: enabling enconding & decoding offset correction! . Thus making us other users waste our precious time. Still more, not to mention those unaware of EAC!!!
Personal benefits aside, best wishes for a near future agreement upon such a feature so needed by end users.

Cheers & Happy New Year! 

PS (to whom it may concern): As for today, US laws are not worldwide applicable... fortunately. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-01-02 01:53:24
sometimes not even correcting their drives' offsets

That's hardly a crime, since CUETools doesn't require offset correction for AR or CTDB verification. What benefit does offset correction have, then?

Besides, if those drives couldn't overread, then you know the samples at the very beginning or end of the rip were actually read from the CD, rather than padded with zeroes. So some might say the non-offset-corrected rip makes for a more accurate copy of the original CD, in terms of content...notwithstanding the silliness of worrying about a few milliseconds'-worth of samples that are most likely silence.

Regarding copyright law, even though just mentioning material of questionable origin isn't a violation or the Hydrogenaudio Terms of Service, it's generally a good idea to avoid doing it, as it turns otherwise helpful people into disdainful curmudgeons.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2012-01-02 06:00:38
That's hardly a crime, since CUETools doesn't require offset correction for AR or CTDB verification. What benefit does offset correction have, then?

Regarding ARv2 verification, I guess my example speaks by itself.
What to do then if you find an old non-matching EAC's log or some AR-disabled log or no log at all?

So some might say the non-offset-corrected rip makes for a more accurate copy of the original CD, in terms of content...notwithstanding the silliness of worrying about a few milliseconds'-worth of samples that are most likely silence.

No point of discussion here. Of course, it's not that important but very useful indeed. Otherwise, it wouldn't even have ever got implemented... I suppose.
That's why I trust CT so hard.

Regarding copyright law, even though just mentioning material of questionable origin isn't a violation or the Hydrogenaudio Terms of Service, it's generally a good idea to avoid doing it, as it turns otherwise helpful people into disdainful curmudgeons.

Let's say I was sneaking my cousin's machine then.
Ssssh!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2012-01-02 10:09:42
What to do then if you find an old non-matching EAC's log or some AR-disabled log or no log at all?

Buy the CD? 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-01-12 16:25:01
Gregory,
I know you're working on CTDB 2.0 and 'ignore pregap' was the last thing you worked on but what's this?
Quote
CTDB: disk not present in database, submit: discs with pregaps not supported in this protocol version.
Looks like discs with pregaps are being rejected in the current CTDB. I don't recall having this message come up on previous submissions.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2012-01-14 19:59:31
I've go strange error when starting conversion, Stream doesnot support lookup.
What does it mean and how to fix it? Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-01-19 17:56:07
Quote
discs with pregaps not supported in this protocol version.
Looks like I get the same CTDB message with CUERipper on discs with pregap.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2012-01-19 20:40:48
HI I see that CUEtools doesnot copy ISRC codes from original CUEsheet to new CUEsheet, could it be fixed in next version?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2012-01-23 15:29:51
I suppose here's another shortcoming: copying old LOG file to new destination converts from Unicode to ANSI. This is basically bad because since this the LOG file can't be checked by EAC log verifier anymore (it only can read LOG files in Unicode). If possible please copy it raw (no codepage conversion). If I overlooked something in options then sorry but I think not, only options to forcing ANSI deals with file names which is different thing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HearingAid on 2012-01-26 06:28:16
Ok so i just started using this wonderful thing CUEtools 2.12a and so far its pretty cool. I don't need to install it and its usb portable which is nice.

The 1st time i used it was on a large album file with its cue file and stuff. I opened it put the mode to "tracks" and without doing nothing else it did a perfect job. I had no idea what i was doing and went on instinct , so i really like the simplicity.
What I want to ask is how the hell did i get a 4 file songs album in .wv (WavPack) turn into .wav files?  I just realized that that extension .wv, WavPack is a lossless format so that shows you how I really don't know much but trying lol.

I think I picked the album folder as the input(cue paths), left everything default and changed the audio output to lossless WAV "builtin wav" (wtf is that) and pressed go. It WORKED and i had nice sounding wav files that play accurately.

I thought this was just a CUE program thing. apparently it can also convert lossless files? what gives. Can I convert from other types of files?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-01-26 11:14:09
I thought this was just a CUE program thing. apparently it can also convert lossless files? what gives. Can I convert from other types of files?

Use cases are outlined on the CUETools homepage (http://www.cuetools.net/wiki/CUETools).
(Not much there, documentation-wise, though).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HearingAid on 2012-01-27 00:11:09
I thought this was just a CUE program thing. apparently it can also convert lossless files? what gives. Can I convert from other types of files?

Use cases are outlined on the CUETools homepage (http://www.cuetools.net/wiki/CUETools).
(Not much there, documentation-wise, though).


"Convert an album image from one lossless codec to another, preserving CUE sheet structure"
"Supports wav, flac, ape, lossywav and wavpack audio input/output. alac is supported for input only."

The first quote I'm a little confused because I'm pretty sure I didn't have an album  "image", just WavPack track files with the cue sheet.
the second quote I know see implies that it can convert (input/output) those type of files. So basically Yes It can be a converter with those specific files. Pretty cool
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-01-27 03:31:46
I'm pretty sure I didn't have an album  "image", just WavPack track files with the cue sheet.

True, an "image" is generally one file containing all the audio. But for purposes of CUETools, an album image just means all the audio data from a CD (except maybe track 01 index 00), and unless further specified, it doesn't matter if that audio data is in one big file or in separate files for each track. Such an "image" stands in contrast to "selected tracks" or some other incomplete portion of a CD; most CUETools functions require a complete rip.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MrMonkey on 2012-02-01 13:35:05
I would like some clarification on a few questions about CueRipper if anyone can help.

If I use CueRipper,exe there doesn't seem to be a way to prepend gaps.  This means that sometimes an HTOA file is created.  No big deal, but it's kind of ugly, especially when it's very small and contains no relevant audio.  (I use 'relevant' in terms of when I add the files to a media player; I realize the relevance of hidden track audio when recreating the original CD.)

There also doesn't seem to be a way to change the name format of the output files.  It's always "%tracknr%. %title".  I would prefer some flexibility in this regard, esp when VA compilations are being ripped.

When I tried ripping by using CueTools.exe, rather than starting CueRipper.exe, I can modify the two above settings.  However, when I try to rip using CueTools.exe, it doesn't appear that metadata/AccurateRip data is queried and filled in.  Am I missing something?

So I'm trying to combine the best of CueRipper.exe and CueTools.exe.  Is the disconnect on my side?

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-01 15:58:31
I would like some clarification on a few questions about CueRipper if anyone can help.

If I use CueRipper,exe there doesn't seem to be a way to prepend gaps.  This means that sometimes an HTOA file is created.  No big deal, but it's kind of ugly, especially when it's very small and contains no relevant audio.  (I use 'relevant' in terms of when I add the files to a media player; I realize the relevance of hidden track audio when recreating the original CD.)
see [a href='index.php?act=findpost&pid=775467']this[/a] for a partial answer and see below.
Quote
There also doesn't seem to be a way to change the name format of the output files.  It's always "%tracknr%. %title".  I would prefer some flexibility in this regard, esp when VA compilations are being ripped.

When I tried ripping by using CueTools.exe, rather than starting CueRipper.exe, I can modify the two above settings.  However, when I try to rip using CueTools.exe, it doesn't appear that metadata/AccurateRip data is queried and filled in.  Am I missing something?
CUERipper config = %appdata%/CUERipper/settings.txt
CUETools config = %appdata%/CUE Tools/settings.txt
CUETools profiles = %appdata%/CUE Tools/profile-{profile_name}.txt (replace {profile_name} with the name of the profile)

There isn't any documentation for this but you can change some of the settings like TrackFilenameFormat= to change the name format in CUERipper to match CUETools. Just compare and copy the desired values from the CUE Tools/settings.txt or profile to CUERipper/settings.txt. Just be sure to make backups before changing anything so you can revert back.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MrMonkey on 2012-02-01 16:44:23
Thanks Korth!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-01 18:03:36
BTW CUETools/CUERipper uses many of the Foobar2000 commands (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Title_Formatting_Reference) so you can make TrackFilenameFormat= 'conditional' in either using Control Flow (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Title_Formatting_Reference#Control_flow) commands.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MrMonkey on 2012-02-01 19:44:28
you can make TrackFilenameFormat= 'conditional' in either using Control Flow (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Title_Formatting_Reference#Control_flow) commands.


I tried using
TrackFilenameFormat=%tracknumber% [- %track artist% - ]- %title%
but CueRipper didn't insert the track artist on compilation tracks.
(I also tried it as %trackartist% just for giggles.)
It just did %tracknumber% - %title%
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-02 00:27:34
I tried using
TrackFilenameFormat=%tracknumber% [- %track artist% - ]- %title%
but CueRipper didn't insert the track artist on compilation tracks.
Sorry, I was referring to conditional track numbering, (single disc = 01,02,03; multidisc = 101,102,103...201,202,203).
I see what you're trying to do but I don't think %track artist% is in the metadata. Not all fields are available from (musicbrains, freedb, ctdb) unfortunately.
For compilation discs, the artist listed on the Tracks page of CUERipper is %artist% and on the Meta page is %album artist%. On single artist discs, both have the same value but only %artist% is written to the tags.

BTW, the syntax you would have needed was
TrackFilenameFormat=$if(%track artist%,%tracknumber% - %track artist% - %title%,%tracknumber% - %title%) had the %track artist% field been available. Putting the spaces and dashes between the [] was incorrect.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-02 01:40:34
[Putting the spaces and dashes between the [] was incorrect.
Well can't re-edit. Ignore that. It would work also if %track artist% had been available.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MrMonkey on 2012-02-02 15:23:47
So then it's just a matter of switching between my two preferred track naming strings for single artist discs versus multi-artist compilations by modifying settings.txt.  Not ideal, but workable.

Any further comment on this part of my original post:
Quote
However, when I try to rip using CueTools.exe, it doesn't appear that metadata/AccurateRip data is queried and filled in. Am I missing something?
?

And thanks again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-02 18:50:36
Quote
However, when I try to rip using CueTools.exe, it doesn't appear that metadata/AccurateRip data is queried and filled in. Am I missing something?
Confirmed and a good question. Maybe someone else knows why.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lasko on 2012-02-04 02:10:37
Hi

Tried searching but couldn't find the answer. Does CUEripper support embedding Album Art when creating a FLAC image? If so, how do I set it up.

Presently CUERipper does everything I need (FLAC Image + CUE, Embedded CUE, extraction log, etc). I am trying to consolidate on a single program.

Thanks
Lasko
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-04 14:16:59
Does CUEripper support embedding Album Art when creating a FLAC image?
link (http://wiki.hydrogenaudio.org/index.php?title=Comparison_of_CD_rippers)
Not currently. Because the source is the CD, it would likely have to be downloaded.
According to the source code repository, coverart search is being added to CTDB 2.0 so it may be a future option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2012-02-05 04:56:42
I have a question concerning the repair option. I ripped a disc using CUERipper. When I inserted the disc, I saw that the CTDB already had one submission for this particular disc. It turned out my particular disc was damaged (three of the tracks would not rip properly) and the AccurateRip results agree. One real problem with the CTDB is that it accepts the bad rip regardless.

No problem, I thought. Since there was already a submission in the CTDB, I'll just repair my bad rip via CUETools. Here's the problem: CUETools is saying my rip is correct because it is checking against the bad rip I had just inadvertently submitted. The log does show that there is another, AR confirmed version of this disc in the CTDB, but unless I'm missing something here, there does not seem to be any way whatsoever that I can have CUETools refer to the *correct* rip in order for me to repair the bad rip. Is there an option that I am overlooking?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-02-05 08:44:15
@Pepzhez - This is the same question I had in the CTDB thread. Gregory's response is [a href='index.php?act=findpost&pid=782763']here (click)[/a].
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2012-02-08 04:33:09
Hey boys, I just ripped a new CD and then (obviously) checked with CT.  Disc was not present in CTDB so, as the faithful CTDB contributor I am  , I submitted when asked.
To my big surprise I found this strange 'discs with pregaps not supported in this protocol version' message. Tried 4 or 5 times more with no avail.
What's this all about?
A new submission policy?
What's the purpose?
I ran out of clues. 

Thanks in advance!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-08 13:35:19
'discs with pregaps not supported in this protocol version' message. Tried 4 or 5 times more with no avail.
What's this all about?
A new submission policy?
What's the purpose?
I ran out of clues. 
I've asked [a href='index.php?act=findpost&pid=782187']here[/a] and [a href='index.php?act=findpost&pid=782923']here[/a] and been asked [a href='index.php?act=findpost&pid=783564']here[/a]. I've had dozens of submissions rejected.
It appears that Gregory is highly focused on the CTDB 2.0 right now. This might just be a temporary byproduct of the new code.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2012-02-09 01:48:14
@Pepzhez - This is the same question I had in the CTDB thread. Gregory's response is [a href='index.php?act=findpost&pid=782763']here (click)[/a].



Thank you! This thread is so unwieldy and long I completely missed that!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2012-02-09 04:01:10
I've asked [a href='index.php?act=findpost&pid=782187']here[/a] and [a href='index.php?act=findpost&pid=782923']here[/a] and been asked [a href='index.php?act=findpost&pid=783564']here[/a]. I've had dozens of submissions rejected.
It appears that Gregory is highly focused on the CTDB 2.0 right now. This might just be a temporary byproduct of the new code.

I'm reading those right now, but I see no answers yet.
Knowing nothing at all of the fact, googled a bit about this new CTDB and found a G+ newsgroup mentioning some 'pregap ignore' from now on, on behalf of per-track ripping mode.
Now, what about those of us who prefer CDImage method for archival and future 'bit-perfect' reproduction purpose? Are we bound to be banned from this new feature?
Sorry but I still see no point on this? It was working so good... 

Regards!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mheitm on 2012-02-09 11:26:09
Cutting up a single FLAC with embedded CUE sheet into per-track FLAC works beautifully from the UI, but when I try to use "cuetools.exe /convert file.flac" from the command prompt there is an error message "Error: Object reference not set to an instance of an object." 
Couple of questions:
Why the error? Maybe somebody knows how one can set the output directory? Come to think of it I'm not even sure how to set the default ouotput format (as mentioned under 'Command Line Options') to get the same result as through the UI.

Thoughts or advice welcome :-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-09 14:43:43
I'm reading those right now, but I see no answers yet.
That was my point. Gregory is either being tight-lipped or is extremely busy.
Quote
found a G+ newsgroup mentioning some 'pregap ignore' from now on
link (https://plus.google.com/u/0/104483163147049308670/posts/HthUiJ7ZSwz) The new beta-version of EAC plugin requires an installer??? I don't like where this is headed now either.
{deleted}
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Manlord on 2012-02-09 23:43:46
I am sure Gregory will come up with a solution to allow submissions with pregap in the database, just give him some time.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: El Kabong on 2012-02-10 02:35:54
link[/url] The new beta-version of EAC plugin requires an installer???

Don't know! I haven't installed and don't think I ever get to.
Who needs a plugin rejecting good rips submissions? Not me. 

I am sure Gregory will come up with a solution to allow submissions with pregap in the database, just give him some time.

Amen!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zodler on 2012-02-10 20:14:51
Hi guys, I used EAC before until I discovered this. It's so much faster than EAC. I have a question and didn't find an answer. I rip to FLAC tracks. However I don't know which Flac to use. There are 4 options in CueRipper:
libFLAC
FLACCL
libFlake
flake
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2012-02-10 20:41:49
Google says:
FLAC (http://flac.sourceforge.net/) (official)
Flake (http://flake-enc.sourceforge.net/)
FLACCL (http://www.cuetools.net/wiki/FLACCL)
(A prefix of lib just means that the host program [in this case, CUETools] will access the given FLAC encoder as a DLL [dynamic linked library] rather than as an executable.)

Basically: If you just want to encode FLAC without worrying too much about probably-small improvements (Flake) or co-processing with your graphics card (FLACCL), then just use the official encoder (flac.exe).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-10 21:22:12
Total newbie to this program here, thank you for this gem.

My query. I've got a load of files that I know the offset is +102 as confirmed by CUETools.

I don't see any point in correcting them (and CUETools warns me when I do it by entering the offset manually I should only do it for temporary files for burning, right?). I'm running CUETools because I want to verify with ARv2.

However, ARv2 doesn't seem to show up in the results for these offset files.. Is this normal?

My quick fix is to run 'Verify' with the 'Offset' box set to 102. Then I get the ARv2 results

Since the log files show that I did this, I'm happy but am I doing 'the right thing'?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-11 03:07:17
However, ARv2 doesn't seem to show up in the results for these offset files.. Is this normal?
see [a href='index.php?act=findpost&pid=755982']this[/a] and several posts that follow.
Quote
My quick fix is to run 'Verify' with the 'Offset' box set to 102. Then I get the ARv2 results
Since the log files show that I did this, I'm happy but am I doing 'the right thing'?
Yes, as you discovered ARv2 will only show when the file offset matches the record but this feature makes verification possible without changing the actual file offset.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-11 10:34:18
However, ARv2 doesn't seem to show up in the results for these offset files.. Is this normal?
see [a href='index.php?act=findpost&pid=755982']this[/a] and several posts that follow.
Quote
My quick fix is to run 'Verify' with the 'Offset' box set to 102. Then I get the ARv2 results
Since the log files show that I did this, I'm happy but am I doing 'the right thing'?
Yes, as you discovered ARv2 will only show when the file offset matches the record but this feature makes verification possible without changing the actual file offset.
Thank you.  The posts on the ARv2 issue are interesting.  I was aware of the issue with v1 but I'm not clear on the CRC and CRC2 issues. More reading to do! I also need to read up on the CTDB. I think for now though, I can batch run CUETools to get the results I wanted.

edit: just watching my batch run. I'm seeing it submit to the CTDB database (a CRC32 of the whole disc, minus the extremes?). Now, I'm guessing it does this when the AR matches, but there is no CTDB entry.  I'm hoping that my manual setting of the offset is fine here :/
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mheitm on 2012-02-11 11:17:18
Can somebody please explain how to use batch mode? Ideally I would like to split all FLAC files in a directory structure into per-track files but I have not found any documentation on the batch functionality, nor have my own attempts worked. Whenever I input a directory as Input Path I get an error message 'Batch mode cannot be used with the output path set manually'. This does not help because I have not found any other way to set it. The Template looks promising but is grayed out and cannot be touched.

Thanks for any help!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zodler on 2012-02-11 11:30:48
So I'm using CueRipper, I'm wondering how can I add an artist to a track? The problem is that if the online database has only one artist for every track, CueRipper doesn't show the artist column next to the track name anymore. Now imagine I want to change one track's artist name, how to show the artist column again so that I can edit it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-11 14:14:32
I input a directory as Input Path I get an error message 'Batch mode cannot be used with the output path set manually'. This does not help because I have not found any other way to set it. The Template looks promising but is grayed out and cannot be touched.
Next to Output: there is a drop-down selection (down arrow). Switch it from Manual to Use template. There is another drop-down next to Input:. There you can switch to Multiselect Browser or Drag'n'drop mode for multiple inputs. Note that the pop-up windows are disabled in batch mode.(http://i44.tinypic.com/dzdm6d.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-11 14:28:31
CueRipper doesn't show the artist column next to the track name anymore.
CUERipper only shows the Artist column next to the track on Various Artists discs. The V/A button doesn't do anything, this is a Known issue (http://www.cuetools.net/wiki/CUERipper). Sorry I can't help.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mheitm on 2012-02-11 15:49:04
I input a directory as Input Path I get an error message 'Batch mode cannot be used with the output path set manually'. This does not help because I have not found any other way to set it. The Template looks promising but is grayed out and cannot be touched.
Next to Output: there is a drop-down selection (down arrow). Switch it from Manual to Use template. There is another drop-down next to Input:. There you can switch to Multiselect Browser or Drag'n'drop mode for multiple inputs. Note that the pop-up windows are disabled in batch mode.


Thanks, works great now with only a top level directory... way cool. This feature was just too hidden for me ;-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wipeout on 2012-02-12 11:07:23
I see what you're trying to do but I don't think %track artist% is in the metadata. Not all fields are available from (musicbrains, freedb, ctdb) unfortunately.
For compilation discs, the artist listed on the Tracks page of CUERipper is %artist% and on the Meta page is %album artist%. On single artist discs, both have the same value but only %artist% is written to the tags.

BTW, the syntax you would have needed was
TrackFilenameFormat=$if(%track artist%,%tracknumber% - %track artist% - %title%,%tracknumber% - %title%) had the %track artist% field been available. Putting the spaces and dashes between the [] was incorrect.


Speaking of musicbrainz metadata, is it possible to add support for things like musicbrainz_albumid, as per http://wiki.musicbrainz.org/MusicBrainz_Picard/Tags/Mapping (http://wiki.musicbrainz.org/MusicBrainz_Picard/Tags/Mapping) ? I embed that value in all my flac image rips to quickly and uniquely identify a release. I just found CUETools and being able to do this in a single step would be mind-bogglingly awesome!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-12 12:14:46
This program is awesome.

I've been doing a lot of reading and googling, and working my way through the thread.

I need a few more pointers though.

I'm checking rips that came from an Olive 4HD.  So, I have FLACS with insecure ripping, offset, no track 1 pregap and no cuesheets.  First I set the offset to 102, correct for the Matsushita in the Olive.  Lots of discs verify fine.  Then I noticed that the CTDB showed pregap times on some of the failures, often at 00:00:32/33.  If I set the 'Pregap' under 'Extra' then they verify fine.

Example with only offset set
Code: [Select]
[CUETools log; Date: 11/02/2012 11:14:50; Version: 2.1.2a]
Offset applied: 102
[CTDB TOCID: jTA_Aihx1LiEMBjpmI3N63ILFak-] found.
[ CTDBID ] Status
[56f6ca88] (215/539) Has pregap length 00:00:33
[3c9c12b9] (324/539) Has pregap length 00:00:33
[AccurateRip ID: 000d9ddc-0064c42e-7909b509] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
 --  87.3 [5803885A] [60C761C3]  
 01  81.5 [73C75AA2] [9081E5B0]  
 02  85.5 [C3D7DDA7] [D3A2F7DF]  
 03  87.3 [6081ACA9] [7F45C852]  
 04  82.3 [E04A93F0] [84D70C9C]  
 05  82.6 [EE52AD19] [73CE1ABC]  
 06  85.7 [88A9933C] [4E334EF9]  
 07  79.6 [4D4C89C6] [E5ED8697]  
 08  76.2 [AAB809E6] [9021DF72]  
 09  83.3 [D8CA945C] [77F0ACC1]

and with the pregap manually set
Code: [Select]
[CUETools log; Date: 12/02/2012 09:42:25; Version: 2.1.2a]
Pregap length 00:00:33.
Offset applied: 102
[CTDB TOCID: jTA_Aihx1LiEMBjpmI3N63ILFak-] found.
[ CTDBID ] Status
[56f6ca88] (215/539) Differs in 10340 samples @00:00:42-00:00:51
[3c9c12b9] (324/539) Accurately ripped
[AccurateRip ID: 000d9f26-0064cb44-7c09b609] found.
Track  [ CRC ] Status
 01 [db7e8d86] (143/673) Accurately ripped
 02 [bb292fb4] (145/672) Accurately ripped
 03 [68cee165] (145/670) Accurately ripped
 04 [56a2afc7] (143/670) Accurately ripped
 05 [3b25294d] (145/670) Accurately ripped
 06 [a04d3f25] (145/674) Accurately ripped
 07 [3152bf90] (141/663) Accurately ripped
 08 [359023eb] (141/667) Accurately ripped
 09 [6f941718] (138/659) Accurately ripped
AccurateRip v2:
 01 [635bedf3] (015/673) Accurately ripped
 02 [d2ac719e] (014/672) Accurately ripped
 03 [09b0f586] (015/670) Accurately ripped
 04 [ddf493c0] (015/670) Accurately ripped
 05 [0bf68518] (015/670) Accurately ripped
 06 [6c2a2238] (015/674) Accurately ripped
 07 [5cf02fcf] (014/663) Accurately ripped
 08 [959a3008] (015/667) Accurately ripped
 09 [75aba5a5] (014/659) Accurately ripped
Offsetted by -1296:
 01 [214d6306] (002/673) Accurately ripped
 02 [7a9d5ce4] (002/672) Accurately ripped
 03 [c8b06385] (002/670) Accurately ripped
 04 [4f751407] (002/670) Accurately ripped
 05 [b69b789d] (002/670) Accurately ripped
 06 [c1a5be85] (002/674) Accurately ripped
 07 [1c2d8710] (002/663) Accurately ripped
 08 [9063389b] (002/667) Accurately ripped
 09 [54f7ed8b] (002/659) Accurately ripped
Offsetted by -389:
 01 [47c192be] (128/673) Accurately ripped
 02 [b144bfa3] (126/672) Accurately ripped
 03 [6a2161ef] (127/670) Accurately ripped
 04 [647b1edb] (127/670) Accurately ripped
 05 [1fcecbc6] (127/670) Accurately ripped
 06 [3855d593] (127/674) Accurately ripped
 07 [05d72e68] (125/663) Accurately ripped
 08 [e2ff4cb2] (128/667) Accurately ripped
 09 [4b344bca] (124/659) Accurately ripped
Offsetted by -18:
 01 [8e3ddeb6] (088/673) Accurately ripped
 02 [0f9905aa] (087/672) Accurately ripped
 03 [c3075889] (086/670) Accurately ripped
 04 [f6892a0f] (085/670) Accurately ripped
 05 [994dea67] (086/670) Accurately ripped
 06 [8efcb2b1] (088/674) Accurately ripped
 07 [22cead00] (085/663) Accurately ripped
 08 [9a614b51] (084/667) Accurately ripped
 09 [5813f1e2] (085/659) Accurately ripped
Offsetted by -537:
 01 [b01f839e] (000/673) No match but offset
 02 [12319edf] (011/672) Accurately ripped
 03 [170e1917] (011/670) Accurately ripped
 04 [a3a9452b] (011/670) Accurately ripped
 05 [098faa2a] (011/670) Accurately ripped
 06 [c66a364b] (011/674) Accurately ripped
 07 [aaee95c8] (011/663) Accurately ripped
 08 [75453b4e] (011/667) Accurately ripped
 09 [d139774b] (010/659) Accurately ripped
Offsetted by -148:
 01 [43dc7e66] (000/673) No match but offset
 02 [1c160ef0] (007/672) Accurately ripped
 03 [15bb988d] (006/670) Accurately ripped
 04 [95d0d617] (007/670) Accurately ripped
 05 [24e607b1] (007/670) Accurately ripped
 06 [2e619fdd] (007/674) Accurately ripped
 07 [d66a26f0] (006/663) Accurately ripped
 08 [c7d61287] (006/667) Accurately ripped
 09 [1e2a5090] (006/659) Accurately ripped
Offsetted by 691:
 01 [62ea8b7e] (000/673) No match but offset
 02 [e70e99fb] (003/672) Accurately ripped
 03 [44e5757f] (003/670) Accurately ripped
 04 [ea7675fb] (003/670) Accurately ripped
 05 [0e4189ae] (003/670) Accurately ripped
 06 [4736c0c3] (003/674) Accurately ripped
 07 [6ccb8828] (003/663) Accurately ripped
 08 [41fa10ca] (003/667) Accurately ripped
 09 [dc8dd15a] (003/659) Accurately ripped
Offsetted by 1212:
 01 [d7d732e6] (000/673) No match but offset
 02 [85bee900] (200/672) Accurately ripped
 03 [034a35ed] (200/670) Accurately ripped
 04 [9d5930d7] (200/670) Accurately ripped
 05 [21c25f21] (200/670) Accurately ripped
 06 [837cdafd] (200/674) Accurately ripped
 07 [580fa170] (200/663) Accurately ripped
 08 [b137c717] (200/667) Accurately ripped
 09 [77f542fe] (200/659) Accurately ripped
Offsetted by 1218:
 01 [9c4217d6] (000/673) No match
 02 [6999a1ae] (000/672) No match but offset
 03 [3a8cb8e1] (000/670) No match
 04 [bd61b2bf] (000/670) No match
 05 [ad0a1ec3] (000/670) No match
 06 [de97b479] (002/674) Accurately ripped
 07 [b23ba7a0] (002/663) Accurately ripped
 08 [8f9cb9f5] (002/667) Accurately ripped
 09 [0e36083e] (002/659) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  87.3 [58E05CB2] [60C761C3]  
 01  81.5 [73C75AA2] [9081E5B0]  
 02  85.5 [C3D7DDA7] [D3A2F7DF]  
 03  87.3 [6081ACA9] [7F45C852]  
 04  82.3 [E04A93F0] [84D70C9C]  
 05  82.6 [EE52AD19] [73CE1ABC]  
 06  85.7 [88A9933C] [4E334EF9]  
 07  79.6 [4D4C89C6] [E5ED8697]  
 08  76.2 [AAB809E6] [9021DF72]  
 09  83.3 [D8CA945C] [77F0ACC1]

Great! Now, I have others where there is no CTDB result so I'm trialling 32/33/37 (from some googling).

Any others I should be trying? Is 00:00:33 zero seconds 33 frames? What about 00:02:00? Any other tips?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-12 18:40:02
I'm checking rips that came from an Olive 4HD
Interesting device (http://www.olive.us/products/music_servers/olive4hd/overview.html).
Quote
Any other tips?
Trying the common pregaps of 32, 33, 37 is a good start.
The discs in question may not be in either database so additional attempts may not help.
Suggestion: re-rip these using CUERipper or EAC w/CTDB plugin (http://www.exactaudiocopy.de/en/index.php/resources/download/) and compare.

a few notes:
Offset is in samples; pregap is in frames (or sectors)
588 samples per frame (sector); 75 frames (sectors) per second; 588*75=44100 samples per second
lead-in of 2 seconds or 150 frames (sectors) is assumed and not needed in CUETools
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-12 20:27:12
I'm checking rips that came from an Olive 4HD
Interesting device (http://www.olive.us/products/music_servers/olive4hd/overview.html).

Off topic but it's a PC motherboard with a nice soundcard and a screen.  It was nearly impossible to get the files off (took Ubuntu to extract from the archive format it uses to backup to on a FAT disk) to save a friend from re-ripping.

I'd set up a Vortexbox to do the same thing.  At least then you have more flexibility and access to the files and you can use Squeezeboxes to play.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-02-14 08:47:15
The V/A button doesn't do anything, this is a Known issue.


Just got this one clarified via the bug tracker on SourceForge:

Quote from: G. Chudov link=msg=0 date=
This button parses freedb entries in 'artist / track' format. It's disabled for non-freedb entries and when track names are not in 'artist / track' format.

It's a similar situation for the Codepage button:

Quote from: G. Chudov link=msg=0 date=
This button is only enabled for freedb entries that are suspected of being non-unicode, and translates them to local codepage. This rarely happens, and never if your local codepage is latin1.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pandev92 on 2012-02-14 13:36:43
Hello, sorry for my porr english but I need your help. I downloaded the latest version of cuetools for split the albums of my japanese collection of music, but seems that the cuetools codification is bad or have a problem, because when I split a track with a japanese carachteres , the spliteed track give the name *?????*and other stranges words .

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-16 00:04:33
when I split a track with a japanese carachteres , the spliteed track give the name *?????*and other stranges words .
Did you uncheck Force ANSI filenames and Remove special characters
in Advanced Settings? Similar question asked [a href='index.php?act=findpost&pid=629375']here[/a] and answered [a href='index.php?act=findpost&pid=629382']here[/a].
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-16 19:14:50
I'm now experimenting with CueRipper and I'm impressed.  I've been using EAC (and REACT) for years, but wow, this is easy to setup.  I *really* like the minimal interface. I think I'd recommend it where I knew the person didn't want to read a book before setting it up.  I might even adopt it myself.

I have a few questions as I can't seem to find any documentation.*

1) Are the three modes: burst, secure and paranoid the same as EAC modes? Secure seems just as fast. Perhaps I need to try some more drives.
2) Does it always Test and Copy as the log implies?.  I usually do T&C with Burst in EAC, but only copy in Secure mode
3) Why does the program produce an EAC log? Is it using something from EAC, or just mimicking it?
4) "Correction files for burst rips with errors are submitted to CTDB" isn't this quite a problem for the CTDB?

*Please don't take this as complaining and I'd like to offer help with documentation if it is needed at all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-16 20:35:19
Another issue.  I want to use CueTools to verify a directory containing directories of albums.  If I use the multiselect browser and tick the top level then under each album it selects the cuesheet and the files.  Then it seems to verify each album twice and wants to overwrite the log.  Can I change this so I don't have to select each cuesheet individually?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-17 05:28:26
1) Are the three modes: burst, secure and paranoid the same as EAC modes?
Not exactly. Paranoid mode in EAC really hammers a drive.
Quote
2) Does it always Test and Copy as the log implies?.  I usually do T&C with Burst in EAC, but only copy in Secure mode
Secure mode in EAC makes at least two passes if C2 isn't set so you are still sort of doing T&C without test showing in the log. CUERipper makes 1 to 31 retries in secure mode and 2 to (I believe) 63 retries in paranoid mode. So that's 2 passes in burst, a minimum of 2 passes in secure and a minimum of 3 passes in paranoid. Note that the log only shows "secure" even when using "paranoid" and only the result of the first 32 passes. So if the error is corrected after 32 passes the error still shows up in the log. No, I haven't asked yet.
Quote
3) Why does the program produce an EAC log? Is it using something from EAC, or just mimicking it?
It's listed as a Known issue (http://www.cuetools.net/wiki/CUERipper). I never asked.
Quote
4) "Correction files for burst rips with errors are submitted to CTDB" isn't this quite a problem for the CTDB?
Everything is submitted but not kept. Gregory is still working on filters.
Quote
*Please don't take this as complaining and I'd like to offer help with documentation if it is needed at all.
Gregory wants us to write documentation for the wiki pages. I too am willing to help but I don't want lead.
Quote
If I use the multiselect browser and tick the top level then under each album it selects the cuesheet and the files.
I believe multiselect is intended for you to make multiple selections. If you select top level in Folder browser, CUETools works more like you want.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-17 08:43:24
Thanks Korth.

It's pretty awesome to see a program that can make great rips so easily.

So, with two passes 'Secure' in CueTools seems like the solution I settled on in EAC, namely Burst mode with Test and Copy.

The known issue is 'Ripper is misreported as ExactAudioCopy v0.99pb4 in cue sheet comment'.  I'm talking about it creating an 'EAC log'.  Just seems odd to me.

With documentation I could only help with the writing, I clearly don't have the knowledge about CueTools yet.  However I learn fast 

I have a few odd logs from scanning my collection that I'll post up when I've pored over them.  I'll have a more thorough read through the thread as well and take some notes.



Cheers again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-02-17 09:18:44
Re: EAC format...Some people want rip logs, and some (most?) of those people want the log to be in the format that EAC uses. Currently the only log that CUERipper produces is in EAC's format. XLD (ripper for Mac OS) writes EAC-style logs, too! I suspect it has something to do with certain file-sharing forums running scripts that check people's uploaded rips, including logs, for various and sometimes dubious measures of quality.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-17 09:59:39
Re: EAC format...Some people want rip logs, and some (most?) of those people want the log to be in the format that EAC uses. Currently the only log that CUERipper produces is in EAC's format. XLD (ripper for Mac OS) writes EAC-style logs, too! I suspect it has something to do with certain file-sharing forums running scripts that check people's uploaded rips, including logs, for various and sometimes dubious measures of quality.
This was pretty much the conclusion that I had come to. Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-17 16:29:38
It seems that CueRipper uses the generally recommended EAC settings:

Code: [Select]
Used drive  : PLEXTOR DVDR   PX-716A   Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 30
[b]Overread into Lead-In and Lead-Out          : No[/b]
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

With EAC I found this drive can overread.  Perhaps I made a mistake, or does CueRipper always set this to 'No'?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-17 17:36:55
With EAC I found this drive can overread.  Perhaps I made a mistake, or does CueRipper always set this to 'No'?
Similar question [a href='index.php?act=findpost&pid=707779']asked[/a] and [a href='index.php?act=findpost&pid=707857']answered[/a]. I have a Plextor CDR capable of Overread into Lead-In and Lead-Out. Also No in CUERipper. It hasn't been an issue on rips so far. Gregory now has a Plextor PX-W1210A and has already added a workaround for that drive in the next version but I don't see anything in the notes about Overread. You might be interested that a Test & Copy checkbox option was added 3 days ago.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-17 18:46:03
Thanks again Korth.  I'm only up to page 9 so far!  Trying to take it all in rather than skim.

As I understand it, by doing at least 2 passes it is already doing test and copy.  The log file shows both CRCs anyway.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-18 07:48:31
With EAC I found this drive can overread.  Perhaps I made a mistake, or does CueRipper always set this to 'No'?
Similar question [a href='index.php?act=findpost&pid=707779']asked[/a] and [a href='index.php?act=findpost&pid=707857']answered[/a]. I have a Plextor CDR capable of Overread into Lead-In and Lead-Out. Also No in CUERipper.
More testing of Cueripper.

When I compare against EAC (with overread) some CDs have identical test CRC32 for the last track.  This will be because CueRipper is filling up the offset with zeroes, and the missed part contained zeros anyway.  My offset is +30. Other CDs do appear to have data to the end.

Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

I suppose it might even be a good feature here for those people correcting offsets if you could check that you are only moving zeroes around (although I understand that correcting offsets has no real benefits, I only enter the offset in the main window to alter the offset for a verify to get the ARv2 result if it wasn't corrected properly at rip)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-02-18 08:54:16
Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

mkdir tmp9 && shntool (http://etree.org/shnutils/shntool/).exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9

(would be simpler if shntool had a "don't write any files" option)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-18 18:42:25
Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?
mkdir tmp9 && shntool (http://etree.org/shnutils/shntool/).exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9

(would be simpler if shntool had a "don't write any files" option)
Clever, but I wasn't thinking straight this morning. "Fill up missing offset samples with silence : Yes" will stop me from testing this way.

I'm testing CueRipper results against EAC. EAC overreads into the lead out with my PLEXTOR DVDR PX-716A (+30 offset)

Am I just being picky wanting my last track CRC32 to match what I get when I run EAC test in burst mode?  It usually does because the last 30 samples are usually digital silence.

I'm just regarding the CRC32 as being superior to the (flawed) AR CRC (and even the v2 has flaws right?). Isn't this why Gregory uses CRC32? Am I wrong here?

Coming soon: How I Learned to Stop Worrying and Love the Rip 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-18 19:20:31
I thought you already figured out that a [a href='index.php?act=findpost&pid=747535']few leading and trailing samples were removed from the CTDB CRC because drives with different offsets and no overread capability will produce different data in those areas[/a]. The link points to a discussion about the localDB but the two are similar.
AR CRCs are also calculated with a few leading samples from the first track and a few trailing samples from the last track removed.
I guess I don't have the same obsession for a possible 30 samples (0.00068 seconds) of inaudible digital noise at the end of the disc if the rest of the disc verifies.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-18 20:24:07
Yes, I know about how AR and CTDB drop the start and end (5 and 10 sectors).  I'm not really worried about those last few samples in my rips.  What I am doing is testing my CueRipper rips against EAC results.  The only way I have to do this is to use the full CRC32 from the EAC log.  As I understand it CRC is less robust (hence why Gregory uses CRC32), and ARv1 is further flawed (hence ARv2).

I guess I'm trying to check if I have one of these errors in EAC, or drive bugs, that I keep hearing about. Greynol might be able to point me in the right direction here. I figured that using two drives and two bits of software would flush any problems out.

It's the scientific training.....just a few more checks and then I'll be happy 

I do think that checking for digital silence could be implemented when people are correcting offsets in CueTools.  I know it has no real benefit to correct the offset and the downside is losing more samples.  But if you check for zeroes, then the downside vanishes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-18 22:26:47
Just finished ripping 80 cds to discover:

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 1  ID: 0
Gap handling: Not detected, thus appended to previous track



Now, I understand that this does not affect the FLACs, but means my cuesheet will have no Index 00.  Other than the negative numbers on a burnt CD there are no bad consequences are there? I read this guide to gaps years ago (http://wiki.hydrogenaudio.org/index.php?title=EAC_Gap_Settings)

I do think the program should warn if it fails gap detection

A couple of other issues.
1) I had a problem where unique didn't work (may have been my fault as I had manually renamed the directory to remove an extraneous 'disc1') and the program simply overwrote the files without asking.  Is this the expected behaviour?
2) I'm trying my other drive in the light of the gap detection.  I see a changed CTDB confidence.  Should I get this increase as a result of my own re-rip? Is it the change of drive?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-20 09:21:49
Just finished ripping 80 cds to discover:

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 1  ID: 0
Gap handling: Not detected, thus appended to previous track
Strange, this is not consistent. Out of 80 cds, 4 were not detected (consistently, with several retries) although one has just had the gaps detected where they weren't before.

This may not be CueRipper though.  I think I recall problems with EAC, although my recollection is that EAC would hang during detection.  This was a long time ago though, so I could be wrong.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2012-02-20 11:25:29
Other than the negative numbers on a burnt CD there are no bad consequences are there?


This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-20 12:17:37
Other than the negative numbers on a burnt CD there are no bad consequences are there?
This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
I always think you need to be careful.  Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2012-02-20 12:42:00
Other than the negative numbers on a burnt CD there are no bad consequences are there?
This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
I always think you need to be careful.  Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.


HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-20 13:29:10
HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.
Yes, of course I agree.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-02-20 14:54:05
Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection
That is how the program notifies you [a href='index.php?act=findpost&pid=706347'][link][/a]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-20 15:44:11
Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection
That is how the program notifies you [a href='index.php?act=findpost&pid=706347'][link][/a]
Cheers korth. It is no problem now that I know this. I looked once I got to that post.

Again, this is a documentation issue. I think I'll make an account for the Cuetools wiki.

And I'm happier now that I see it wasn't all the rips I had completed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pontomedon on 2012-02-24 10:14:30
I hope this is the right place to ask - I have the following problem: I ripped a CD (The Lion King OST) in EAC, resulting in a few errors in one track, every other track was verified OK by AccurateRip:

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 23. February 2012, 20:09

Various / The Lion King OST

Used drive  : HL-DT-STDVD-ROM GDR-H30N  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  3:59.67 |        0    |    17991 
        2  |  3:59.67 |  2:50.73 |    17992    |    30814 
        3  |  6:50.65 |  3:40.15 |    30815    |    47329 
        4  | 10:31.05 |  3:33.50 |    47330    |    63354 
        5  | 14:04.55 |  2:57.52 |    63355    |    76681 
        6  | 17:02.32 |  2:55.33 |    76682    |    89839 
        7  | 19:57.65 |  4:17.50 |    89840    |  109164 
        8  | 24:15.40 |  3:45.17 |    109165    |  126056 
        9  | 28:00.57 |  5:59.05 |    126057    |  152986 
      10  | 33:59.62 |  4:51.50 |    152987    |  174861 
      11  | 38:51.37 |  3:36.73 |    174862    |  191134 
      12  | 42:28.35 |  3:59.45 |    191135    |  209104 


Range status and errors

Selected range

    Filename Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.wav

    Suspicious position 0:41:22
    Suspicious position 0:41:26

    Peak level 98.3 %
    Extraction speed 9.3 X
    Range quality 99.6 %
    Copy CRC 201635C8
    Copy finished

There were errors

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 5)  [8F75F0CE]  (AR v2)
Track  2  accurately ripped (confidence 5)  [B94FCBF7]  (AR v2)
Track  3  accurately ripped (confidence 5)  [057830A9]  (AR v2)
Track  4  accurately ripped (confidence 5)  [9072E0B2]  (AR v2)
Track  5  accurately ripped (confidence 5)  [45BC209F]  (AR v2)
Track  6  accurately ripped (confidence 5)  [69A80D86]  (AR v2)
Track  7  accurately ripped (confidence 5)  [CEFBBEB7]  (AR v2)
Track  8  accurately ripped (confidence 5)  [54A17B6F]  (AR v2)
Track  9  accurately ripped (confidence 5)  [377CD6A5]  (AR v2)
Track 10  accurately ripped (confidence 5)  [5942A28C]  (AR v2)
Track 11  cannot be verified as accurate (confidence 94)  [AC42013C], AccurateRip returned [47CF4212]  (AR v2)
Track 12  accurately ripped (confidence 5)  [B2C61F12]  (AR v2)
 
11 track(s) accurately ripped
 1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: V1WRWT9HKBEErwwrV9RGpqqiZP8-] found, Submit result: V1WRWT9HKBEErwwrV9RGpqqiZP8- has been submitted
[fc6cb270] (162/168) Differs in 9300 samples @41:20:11-41:20:12,41:20:28-41:20:29,41:20:44-41:20:45,41:20:61-41:20:62,41:21:02-41:21:03,41:21:19-41:21:20,41:21:35-41:21:36,41:21:52-41:21:53,41:21:68-41:21:69,41:22:10-41:22:11,41:22:26-41:22:27,41:22:43-41:22:44,41:22:59-41:22:60,41:23:01-41:23:02,41:23:17-41:23:18,41:23:34-41:23:35,41:23:50-41:23:51,41:23:67-41:23:68,41:24:08-41:24:09,41:24:25-41:24:26,41:24:41-41:24:42,41:24:58-41:24:59,41:24:74-41:25:00,41:25:16-41:25:17,41:25:32-41:25:33,41:25:49-41:25:50,41:25:65-41:25:66,41:26:07-41:26:08,41:26:23-41:26:24,41:26:40-41:26:41,41:26:56-41:26:57,41:26:73-41:26:74,41:27:15,41:27:31-41:27:32,41:27:48,41:27:64-41:27:65,41:28:06,41:28:22-41:28:23
[d03a4fda] (001/168) No match
[557785fe] (001/168) No match
[8036c248] (001/168) No match
[e23534ca] (001/168) No match
[523a016f] (001/168) No match
[9d808615] (001/168) No match
You can use CUETools to repair this rip.


I've never used CUETools before, but i wanted to give it a try to repair the rip. When i load the cue file, and run the encode mode with the repair script selected it verifies the tracks and then stops with the message

Code: [Select]
Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.cue: differs in 9300 samples, confidence 163, or verified OK, confidence 1.

Sounds like there are multiple entries in the CTDB database, i might even have uploaded the incorrect one myself, as EAC states "has been submitted" in the log. Is there a possibility to repair the rip?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-24 11:25:03
Is there a possibility to repair the rip?

It looks like you are getting the batch mode log, select the cue sheet before you click go.  Cuetools should then ask you which entries in CTDB you want to use for the repair.

I've also had a few issues where I've had to ask it to repair several times.  Initially it goes through the verify and stops, then the next time it works and I'm not sure why.  Someone else might be able to shine some light on this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pontomedon on 2012-02-24 11:47:52
Ah thank you, i was using the batch mode, it worked now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-02-24 12:57:47
Ah thank you, i was using the batch mode, it worked now.
Glad to help.  I've only been using CueTools for a week and I've been doing all the asking until now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BrassDude on 2012-03-03 18:41:30
I'm using the latest version of CUETools 2.1.2a for verifying my rips and populating the CTDB. I found a problem with multi-disc albums that have 5 or more discs if each disc is ripped into multiple tracks. CUETools nicely detects the individual discs if the files are propperly tagged - but only to a maximum of 5 discs. If there are more than 5 disc for that album, all the remaining tracks are grouped in one big disc - the 5th one. Is there a parameter that I can set (max. discs) or is this a bug? Of course if each disc is ripped into a single flac file then there is no problem with the multi-disc albums.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-03-03 18:56:56
You can switch Input to Multiselect Browser and select cues for more than 5 discs. Detection (as you put it) does max out at 5.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BrassDude on 2012-03-04 03:44:58
Thanks for your help korth. Can you be a bit more specific - I didn't really understand and see where I can switch to Multiselect Browser.

Also why is this magic number 5 hardcoded? There are many album box-sets out there with definitely more than 5 discs. Maybe that could be a parameter in a future version that one could set under the options. :-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-03-04 04:16:34
See the down arrow after Input:? Click on it.(http://i44.tinypic.com/dzdm6d.jpg)
Quote
Also why is this magic number 5 hardcoded?
That I can't answer. Only know it from my own usage. Gregory seems quite busy the past few months so I just help out when I can answer a question.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-03-05 13:00:27
I know I am replying to some > 3 year old post [a href="index.php?act=findpost&pid=593800"][{POST_SNAPBACK}][/a], but, concerning AccurateRip retro-verification:

i'm still quite pessimistic about the possibility of recovering an album structure, when tracks were split. Ok, we can sacrifice that split track and focus on verifying other tracks, but for that we have to know for sure it's length.


A suggestion for the case where a cuesheet is absent:
(I) Check files for ACCURATERIPID tags. Then users who use CUERipper, will be able to retro-check AR status later, without the cuesheet (and users who read this forum, could very often get the impression that cuesheets are only useful for writing back a copy ...)
(II) Check files for AccurateRipDISCId tags (my emph.). dBpoweramp writes those. CUERipper and dBpoweramp users are a minority compared to EAC users, but if you consider (I) to be worthwile support for CUERipper users, it should be hardly much effort to do dBpoweramp's tag as well.
(III) Could CDTOC be used the same way? MusicBrainz IDs?


(... 72 pages and counting ... if you could even find information in this thread, you wouldn't know if it is up-to-date :-o )
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2012-03-05 20:16:09
I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-03-05 21:24:42
I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?
Because of the way accuraterip works, I would rip the whole CD in track mode then just grab the tracks I wanted.  Or you could use EAC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: IceFreak2000 on 2012-03-10 12:07:32
Whenever I try to rip a CD using CueRipper, I always get an error stating that there were 15 suspicious sectors, although the rip has been confirmed with Accurip; for an example, the CD I've just tried produced the following Accurip file:

Code: [Select]
[CUETools log; Date: 10/03/2012 11:30:36; Version: 2.1.2a]
[CTDB TOCID: _uGvLH10IxqfR4ZETg_p5mkWEpw-] found.
        [ CTDBID ] Status
        [215e14c2] (1/2) Differs in 710 samples @58:26:43-58:26:44
        [9e9c6c34] (1/2) Accurately ripped
[AccurateRip ID: 001f4d67-016255cf-c70db20f] found.
Track  [ CRC    ] Status
 01    [0729a137] (04/32) Accurately ripped
 02    [6dc2ef07] (04/32) Accurately ripped
 03    [942a1c47] (04/32) Accurately ripped
 04    [3e9c91b6] (04/32) Accurately ripped
 05    [00f5b2e0] (04/32) Accurately ripped
 06    [8ec50bcd] (04/32) Accurately ripped
 07    [228a631f] (04/32) Accurately ripped
 08    [084ab80e] (04/32) Accurately ripped
 09    [ba9a8ed6] (04/31) Accurately ripped
 10    [b4faabe6] (04/32) Accurately ripped
 11    [4c61993f] (04/32) Accurately ripped
 12    [980f5e20] (04/32) Accurately ripped
 13    [51070d0f] (04/31) Accurately ripped
 14    [ce9d5a83] (04/31) Accurately ripped
 15    [1f5281df] (04/29) Accurately ripped
Offsetted by 1879:
 01    [1321ed77] (02/32) Accurately ripped
 02    [2a4a5c4e] (02/32) Accurately ripped
 03    [5a28826a] (02/32) Accurately ripped
 04    [3f160e1d] (02/32) Accurately ripped
 05    [592e74cf] (02/32) Accurately ripped
 06    [388dbbda] (02/32) Accurately ripped
 07    [124d08a5] (02/32) Accurately ripped
 08    [4edeb39b] (02/32) Accurately ripped
 09    [408366d0] (02/31) Accurately ripped
 10    [8ebca252] (02/32) Accurately ripped
 11    [06f884e7] (02/32) Accurately ripped
 12    [cc92ee8c] (02/32) Accurately ripped
 13    [0552cee7] (02/31) Accurately ripped
 14    [13c98641] (02/31) Accurately ripped
 15    [e1889663] (02/29) Accurately ripped
Offsetted by 2713:
 01    [e03f2aff] (16/32) Accurately ripped
 02    [40038405] (16/32) Accurately ripped
 03    [3ecee28a] (16/32) Accurately ripped
 04    [88447f34] (16/32) Accurately ripped
 05    [0cfba08e] (16/32) Accurately ripped
 06    [d058da0d] (16/32) Accurately ripped
 07    [fd5ff960] (16/32) Accurately ripped
 08    [63891968] (16/32) Accurately ripped
 09    [721e03c5] (15/31) Accurately ripped
 10    [b1f79bc8] (16/32) Accurately ripped
 11    [ab29209d] (16/32) Accurately ripped
 12    [cfbabb8f] (16/32) Accurately ripped
 13    [c8cb2ec1] (15/31) Accurately ripped
 14    [8e80b899] (15/31) Accurately ripped
 15    [d0512438] (00/29) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  99.9 [0EDAF71A] [3E355924]         
 01  93.2 [88F41CD8] [D57DC7E0]         
 02  72.5 [C64A2F25] [A6B1C7EA]         
 03  95.4 [BBA16AB2] [3FD6FC02]         
 04  87.3 [236D2E8E] [103E0353]         
 05  80.7 [038E3D95] [1A09CAB9]         
 06  94.6 [DF0DF23F] [4DFC12DD]         
 07  84.2 [6A17FA2E] [BDC00B01]         
 08  99.9 [3A5BA7CD] [D07AC925]         
 09  90.9 [2E4D3AE1] [E8914DFB]         
 10  88.0 [9AC6C7C8] [BD3FF92A]         
 11  74.9 [023E329B] [4CBE857B]         
 12  87.1 [A3F378CF] [E5B9B1CC]         
 13  92.4 [DE103A96] [7A326BE4]         
 14  75.0 [52A4E116] [5B5BFA5A]         
 15  69.6 [2391AED3] [0C0A645C]         

The CueRipper log shows:

Code: [Select]
CUERipper v2.1.2 Copyright © 2008-10 Gregory S. Chudov

EAC extraction logfile from 10. March 2012, 11:30

Motörhead / All the Aces: The Best of Motörhead

Used drive  : HL-DT-ST DVDRAM GH20NS15  Adapter: 1  ID: 0

Read mode              : Burst
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  2:48.30 |        0    |    12629 
        2  |  2:48.30 |  4:34.72 |    12630    |    33251 
        3  |  7:23.27 |  4:43.50 |    33252    |    54526 
        4  | 12:07.02 |  2:52.60 |    54527    |    67486 
        5  | 14:59.62 |  5:22.53 |    67487    |    91689 
        6  | 20:22.40 |  3:21.62 |    91690    |  106826 
        7  | 23:44.27 |  3:09.20 |    106827    |  121021 
        8  | 26:53.47 |  3:40.15 |    121022    |  137536 
        9  | 30:33.62 |  4:16.53 |    137537    |  156789 
      10  | 34:50.40 |  2:46.02 |    156790    |  169241 
      11  | 37:36.42 |  2:39.03 |    169242    |  181169 
      12  | 40:15.45 |  4:27.02 |    181170    |  201196 
      13  | 44:42.47 |  3:15.28 |    201197    |  215849 
      14  | 47:58.00 |  5:11.35 |    215850    |  239209 
      15  | 53:09.35 |  5:17.15 |    239210    |  262999 


Range status and errors

Selected range

    Filename D:\Rip\Motörhead\1993 - All the Aces_ The Best of Motörhead\Motörhead - All the Aces_ The Best of Motörhead.wav

    Suspicious position 0:57:54

    Peak level 99.9 %
    Range quality 100.0 %
    Test CRC 0EDAF71A
    Copy CRC 0EDAF71A
    Copy OK

There were errors


AccurateRip summary

Track  1  accurately ripped (confidence 4)  [0729A137]
Track  2  accurately ripped (confidence 4)  [6DC2EF07]
Track  3  accurately ripped (confidence 4)  [942A1C47]
Track  4  accurately ripped (confidence 4)  [3E9C91B6]
Track  5  accurately ripped (confidence 4)  [00F5B2E0]
Track  6  accurately ripped (confidence 4)  [8EC50BCD]
Track  7  accurately ripped (confidence 4)  [228A631F]
Track  8  accurately ripped (confidence 4)  [084AB80E]
Track  9  accurately ripped (confidence 4)  [BA9A8ED6]
Track 10  accurately ripped (confidence 4)  [B4FAABE6]
Track 11  accurately ripped (confidence 4)  [4C61993F]
Track 12  accurately ripped (confidence 4)  [980F5E20]
Track 13  accurately ripped (confidence 4)  [51070D0F]
Track 14  accurately ripped (confidence 4)  [CE9D5A83]
Track 15  accurately ripped (confidence 4)  [1F5281DF]

All tracks accurately ripped

End of status report

Any ideas why CueRipper should be reporting an error? Is it something to do with my drive?

When ripping with EAC + CTDB, I get the following:

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 10. March 2012, 12:02

Motörhead / All the Aces: The Best of Motörhead

Used drive  : HL-DT-STDVDRAM GH20NS15  Adapter: 4  ID: 1

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format              : User Defined Encoder
Selected bitrate                : 896 kBit/s
Quality                        : High
Add ID3 tag                    : Yes
Command line compressor        : C:\Program Files (x86)\Exact Audio Copy\FLAC\FLAC.EXE
Additional command line options : -6 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "BAND=%albuminterpret%" -T "ALBUMARTIST=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" %hascover%--picture="%coverfile%"%hascover% %source% -o %dest%


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  2:48.30 |        0    |    12629 
        2  |  2:48.30 |  4:34.72 |    12630    |    33251 
        3  |  7:23.27 |  4:43.50 |    33252    |    54526 
        4  | 12:07.02 |  2:52.60 |    54527    |    67486 
        5  | 14:59.62 |  5:22.53 |    67487    |    91689 
        6  | 20:22.40 |  3:21.62 |    91690    |  106826 
        7  | 23:44.27 |  3:09.20 |    106827    |  121021 
        8  | 26:53.47 |  3:40.15 |    121022    |  137536 
        9  | 30:33.62 |  4:16.53 |    137537    |  156789 
      10  | 34:50.40 |  2:46.02 |    156790    |  169241 
      11  | 37:36.42 |  2:39.03 |    169242    |  181169 
      12  | 40:15.45 |  4:27.02 |    181170    |  201196 
      13  | 44:42.47 |  3:15.28 |    201197    |  215849 
      14  | 47:58.00 |  5:11.35 |    215850    |  239209 
      15  | 53:09.35 |  5:17.15 |    239210    |  262999 


Range status and errors

Selected range

    Filename D:\Rip\Motorhead - All The Aces\Motörhead - All the Aces- The Best of Motörhead.wav

    Peak level 99.9 %
    Extraction speed 28.2 X
    Range quality 100.0 %
    Copy CRC 0EDAF71A
    Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 4)  [0729A137]  (AR v1)
Track  2  accurately ripped (confidence 4)  [6DC2EF07]  (AR v1)
Track  3  accurately ripped (confidence 4)  [942A1C47]  (AR v1)
Track  4  accurately ripped (confidence 4)  [3E9C91B6]  (AR v1)
Track  5  accurately ripped (confidence 4)  [00F5B2E0]  (AR v1)
Track  6  accurately ripped (confidence 4)  [8EC50BCD]  (AR v1)
Track  7  accurately ripped (confidence 4)  [228A631F]  (AR v1)
Track  8  accurately ripped (confidence 4)  [084AB80E]  (AR v1)
Track  9  accurately ripped (confidence 4)  [BA9A8ED6]  (AR v1)
Track 10  accurately ripped (confidence 4)  [B4FAABE6]  (AR v1)
Track 11  accurately ripped (confidence 4)  [4C61993F]  (AR v1)
Track 12  accurately ripped (confidence 4)  [980F5E20]  (AR v1)
Track 13  accurately ripped (confidence 4)  [51070D0F]  (AR v1)
Track 14  accurately ripped (confidence 4)  [CE9D5A83]  (AR v1)
Track 15  accurately ripped (confidence 4)  [1F5281DF]  (AR v1)
 
All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: _uGvLH10IxqfR4ZETg_p5mkWEpw-] found, Submit result: _uGvLH10IxqfR4ZETg_p5mkWEpw- has been confirmed
[215e14c2] (1/3) Differs in 710 samples @58:26:43-58:26:44
[9e9c6c34] (2/3) Accurately ripped
You can use CUETools to repair this rip.


==== Log checksum B86A826E81C4C480ECB0ED5FE371F678BA6921EE19A4E62D0D7B5754B5A01B10 ====



Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-03-10 12:50:48
Shooting from the hip:

- This is at the end of the album. Are you using an old EAC? Think there were some end-of-CD issues up to 0.94 or something like that.
- Suspicious sectors may be a manufactoring defect on the CD. Then all CDs (of the same pressing, at least) have the same issue, and you could end up getting the same rip as someone else even for the 'suspicious' part. In that case, there is probably nothing you could do to improve.
- Could this be a lead-out issue? No? It is too many seconds left?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-03-10 14:44:28
Do you always rip in Burst Mode with CUERipper? Burst mode is only two passes. Secure Mode is minimum 2 but up to 32.
The EAC rip is in Secure Mode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: IceFreak2000 on 2012-03-10 14:52:01
Shooting from the hip:

- This is at the end of the album. Are you using an old EAC? Think there were some end-of-CD issues up to 0.94 or something like that.
- Suspicious sectors may be a manufactoring defect on the CD. Then all CDs (of the same pressing, at least) have the same issue, and you could end up getting the same rip as someone else even for the 'suspicious' part. In that case, there is probably nothing you could do to improve.
- Could this be a lead-out issue? No? It is too many seconds left?


I'm using EAC 1.0 beta 3; that's the latest version right?

The '15 suspicious errors' report happens every time with CueRipper for *any* CD that I attempt with it.

Do you always rip in Burst Mode with CUERipper? Burst mode is only two passes. Secure Mode is minimum 2 but up to 32.
The EAC rip is in Secure Mode.


No, I've tried Secure and Paranoid modes in CueRipper and apart from exponentially increasing the time taken to rip it always produces the same result
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-03-11 11:00:31
Are the errors always right at the end of the disc? They are for the log you posted. 

This is why the rip passes accuraterip.  It should also pass CTDB. I'm not sure what the CTDB issues are with this disc.  Do you usually get a good CTDB result?

I think it is the drive, it seems to be like when a drive that cannot overread is asked to (although CueTools does not overread).  This is a complete speculation though.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-03-11 14:38:52
This is why the rip passes accuraterip.
I know the logs are hard to read as posted. The (possible) error in the CUERipper log as posted occurred between 31 & 32 seconds from the end of the disc. Too far to pass accuraterip on an offset issue. I said possible error because the CRC32s are the same in both logs and the EAC log had no errors reported.
Quote
it seems to be like when a drive that cannot overread is asked to
It does (sort of) resemble the error that occurs when overread is incorrectly enabled in EAC.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lipidicman on 2012-03-11 15:12:14
Yes, I was looking at Differs in 710 samples @58:26:43-58:26:44, rather than Suspicious position 0:57:54

Odd.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2012-03-25 10:27:26
Hello there,

I am in the process of verifying my rips, all of which are encoded with TAK 2.2.0. Most of the time, everything is going well, but sometimes (and rather randomly), I get an error message saying "Unable to read beyond the end of the stream..". I can use foobar2000's verification plug-in without any problems on the same files, but I'd like to do it with CUETools due to the fact that it supports AR v2 and the CTDB.

What could be causing this? The path to the TAK command-line tool is correctly specified and so are the command-line parameters (-d %I -).

Thanks in advance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: krafty on 2012-04-05 16:50:56
any chance of having this tool natively on linux
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2012-04-05 17:04:36
Depends. As it is written in C#, you'd need the Mono framework anyway.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-05 17:06:57
Well, it's written in C# and i have no plans to rewrite it in any other language, so if you don't count mono as 'natively', then the answer is no. What i was considering to do, but haven't found the time, is to at least test it on linux before releasing each version, and maybe create a separate download where it's bundled with mono libs using mkbundle, but i'm not sure how will plugins work in this scenario.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-12 04:44:47
I need help to decide on tag mapping in CUETools.
CTDB metadata contains at least three useful pieces of data that aren't currently written as tags. Those are Release Date, Label and Catalog#.
When using FLAC, i was planning on storing them as "RELEASEDATE", "LABEL" and "LABELNO".
According to http://sublevelseven.com/resources/1/ (http://sublevelseven.com/resources/1/), those should map to "TDRL", "labl"  and "cat#" in mp4, and to "TDRL", "TPUB" and ?nothing in mp3.
But foobar2k maps "TDRL" to "RELEASE DATE" and "TPUB" to "PUBLISHER". I'm confused.
Also no idea how to store release country and disc name .
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-04-12 16:41:12
Quote
But foobar2k maps "TDRL" to "RELEASE DATE" and "TPUB" to "PUBLISHER". I'm confused.
Isn't "ALBUM ARTIST" unique to foobar2k (and CUETools)?

I'd say "RELEASEDATE",  "PUBLISHER", and "CATALOG" but don't see why foobar2k's "RELEASE DATE" or your choice of "LABEL" and "LABELNO" wouldn't work also.
Quote
Also no idea how to store release country and disc name.
You're getting into "User defined" or "TXXX" territory with "Release Country" and "Disc Name". I'd say "COUNTRY" or "RELEASECOUNTRY" and "DISCNAME"

But this is just my 2 cents. Additional discussion welcome.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2012-04-13 19:40:23
Here are some facts regarding LABEL / PUBLISHER and foobar2000:
-For VorbisComment (FLAC), foobar2000 prefers PUBLISHER over ORGANIZATION (Label). It shows values from those fields only as PUBLISHER in the properties of a file.
-foobar2000 can not read multiple values in the TPUB (PUBLISHER) field in ID3v2.

So, if you want to base your tags on foobar2000, I'd go with PUBLISHER for VorbisComment. I don't know if you need multiple values for ID3v2, but if you do, I'd use a custom TXXX frame. If not, TPUB would work fine.

I would also use TYER (ID3v2.3) / TDRC (ID3v2.4) instead of TDRL for the release date. As far as I know, the usage of TYER/TDRC is vast compared to TDRL, which is very rarely used. DATE for VorbisComment.

As for the other tags, personally I'm using the custom tags CATALOG NUMBER (except CATALOG for APEv2 and CATALOG_NUMBER for Matroska, which are specified), DISCNAME and RELEASE LOCATION.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-13 20:04:27
Thank you. One clarification: i mentioned TDRL, because i want to store release date, as opposed to recording date or original release date, which is usually stored as TYER/TDRC. For example, the latest remaster of Pink Floyd's DSotM would have TDRC=1973 and TDRL=2011. Although according to spec, TDRL is also supposed to store original release date
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2012-04-13 20:28:52
Yes, I know. I wanted to use TDRL at first too, but everyone's using TYER/TDRC for release date (even though it's actually recording date), so for compatibility, I went with it, too. It's kind of a mess.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-13 21:18:15
Both discogs & muscibrainz return two dates, and i already use TYER for recording/original release date, so i have to use something different for actual release date in case of remastered albums. If i were to use TYER for actual release date, this would only lead to question  where to store original release date... TORY isn't well used either. What's more importantly, all software that i know of uses TYER for sorting/browsing music library, so that's where people tend to put original release date, because who wants to sort their library by the date of the remastered release. And for those who still want to keep track of remasters, TDRL will probably have to do.

Some news about release country: TagLib has MusicBrainzReleaseCountry field, which used "RELEASECOUNTRY" for VorbisComment and APEv2, and TXXX MusicBrainz Album Release Country for mpeg... They seem to use http://wiki.musicbrainz.org/PicardQt/TagMapping (http://wiki.musicbrainz.org/PicardQt/TagMapping)

This document also recommends DISCSUBTITLE/TSST for disc name.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-04-14 05:35:20
Both discogs & muscibrainz return two dates

Discogs returns two dates? How? They don't store original dates. At the release level, there's only one date, the actual date of release.

all software that i know of uses TYER for sorting/browsing music library, so that's where people tend to put original release date, because who wants to sort their library by the date of the remastered release.

Not that I have access to very many people's collections to verify, but from what I've seen, it's quite rare to have more than one date in tags: the one date provided is nearly always the actual release date (year alone, usually), as that's all that the metadata sources tend to provide. The situation is the same in the digital releases I've purchased.

I do prefer my TYER to be the original release date, so I make that change and then put the remaster/compilation date in prose in COMM because I don't know what else to do (in foobar2000). I think most people don't even bother; if the music is from 1977 but the reissue/remaster/compilation came out in 2008, probably the TYER is already set to 2008, and they just leave it as-is.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-14 23:55:32
Both discogs & muscibrainz return two dates

Discogs returns two dates? How? They don't store original dates. At the release level, there's only one date, the actual date of release.

Each release belongs to a release group (musicbrainz) or master release (discogs), which stores original release date.
I'm talking about musicbrainz/discogs data as returned by CTDB, which provides both dates.

I do prefer my TYER to be the original release date

Exactly. So i think CUETools should do the same, and store remaster date in TDRL.
We all know that the world of tag mapping is in a complete mess, but something has to be done, we can't just give up
In the last few days i've read about a dozen different tag mapping documents from various software vendors, and it's given me a headache.
They cannot agree on anything. So i guess i'll just have to use my own judgement in each case and at least try not to create new names for the same entities.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-04-15 06:11:59
Each release belongs to a release group (musicbrainz) or master release (discogs), which stores original release date.

Sort-of, but not exactly. The year reported in the Discogs master release is just the earliest year from among the actual release dates of the releases in the set. For albums and singles, this can be safely interpreted as the original release date, and usually it works for the songs on the release. But this interpretation fails for most compilations, or any other album on which there are songs culled from prior years. On those types of releases, a given song's original release date is almost never the same as the release date of any edition of the compilation. So if you're tagging individual tracks, there's no easy way to use Discogs data to get actual original release dates for each song, at least not without some creative use of the search engine.

I don't recall what MusicBrainz does, but I think it's the same kind of situation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-15 07:56:18
In musicbrainz you can actually find the first release date of a given recording, even if it was released in different release groups.
Each track of each release has a link to a recording, for example here is 'The End' by 'The Doors': http://musicbrainz.org/recording/1423fcd8-...75-082af4ba45c1 (http://musicbrainz.org/recording/1423fcd8-31f1-4ced-9c75-082af4ba45c1)
You can easily see that the original release date for this recording is 1967-01-04, and you can get to this data from any compilation release.
But CTDB currently doesn't return this data, i'm not sure how relevant it is.

Anyways, this would probably be a third tag  For example, a track originally released in in 1967, included in 2001 remaster of 1995 compilation could have TDOR=1967, TYER=1995, TDRL=2001.
Putting individual track release years in TYER could lead to strange behavior in many applications, because the tracks from this compilation could end up in different folders, or in different groups in the playlist.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2012-04-15 22:36:57
Gregory, do you have a possible explanation of this:

Hello there,

I am in the process of verifying my rips, all of which are encoded with TAK 2.2.0. Most of the time, everything is going well, but sometimes (and rather randomly), I get an error message saying "Unable to read beyond the end of the stream..". I can use foobar2000's verification plug-in without any problems on the same files, but I'd like to do it with CUETools due to the fact that it supports AR v2 and the CTDB.

What could be causing this? The path to the TAK command-line tool is correctly specified and so are the command-line parameters (-d %I -).

Thanks in advance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-15 22:39:58
Sorry, i haven't got around to this yet.

UPD: tried to reproduce it, but couldn't. In theory this can only happen if takc.exe crashes on startup.
foobar2000 uses foo_input_tak.dll instead of takc.exe, so it's not affected.
I wanted to switch to TAK SDK in CUETools, but it only provides 32-bit dll.
And frankly, i don't want to waste any time on a codec for which there's no open-source decoder.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-17 04:04:43
CUETools 2.1.4 is out, http://www.cuetools.net/install/CUETools_2.1.4.rar (http://www.cuetools.net/install/CUETools_2.1.4.rar)
If no serious bugs will be found in the next few days, this will be declared the new stable version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2012-04-17 06:11:09
there seems to be a bug in the multi select browser when pressing f5 to refresh. although the "local db" node is present, it cannot be expanded to view anything and it takes a restart to work again.

edit: using + and * keyboard shortcuts around my numpad works but i'm pretty sure it could be done with the mouse before.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-17 06:18:54
I think it can be expanded - just select it and press right arrow on the keyboard. But i'll fix it of course
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-04-17 19:33:47
Quote
CUETools 2.1.2 is out!
Please don't forget to update the version info under "Check for updates"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: OpTicaL on 2012-04-18 07:24:08
CUETools says it needs .NET Framework 2.0 (SP2) to run but what if I have .NET Framework 4 installed? Do I still need to install .NET Framework 2.0 SP2?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-18 07:33:43
No.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: OpTicaL on 2012-04-18 20:33:29
Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hbonded on 2012-04-19 08:01:43
I've been encountering some situations in which I am unable to perform a repair on a defective rip. When the "repair" script is used, CUETools simply verifies the rip without proceeding with the repair although the log suggests that a repair is possible. This issue seems to affect those with discs with multiple entries in the database. Perhaps CUETools is "confused" by the various CTDB submissions and is unable to choose upon which disc to base its repair. Both the 2.1.2a and 2.1.4 versions exhibit this behavior. I was wondering if anyone else is experiencing this issue.

Here is an example of a disc for which a repair fails. I am attempting to perform a repair of the first track based on the 3 disc submissions (out of 4) in the database that I presume represent the "accurate" rip. As you can see, one of the 4 submissions appears to have some errors in the last track judging from the AccurateRip results. Is there a way for CUETools to select the most likely "proper" rip for repair?

Code: [Select]
[CUETools log; Date: 4/18/2012 11:23:32 PM; Version: 2.1.4]
[CTDB TOCID: r81jSzMBwJxxnkcsRBbGivrNHBA-] found.
[ CTDBID ] Status
[abc01ed8] (3/4) Differs in 4 samples @00:01:18
[8ac12682] (1/4) Differs in 9016 samples @00:01:18,55:48:31-55:48:39
Track | CTDB Status
 1  | (3/4) Differs in 4 samples @00:01:18, or (1/4) differs in 4 samples @00:01:18
 2  | (4/4) Accurately ripped
 3  | (4/4) Accurately ripped
 4  | (4/4) Accurately ripped
 5  | (4/4) Accurately ripped
 6  | (4/4) Accurately ripped
 7  | (4/4) Accurately ripped
 8  | (4/4) Accurately ripped
 9  | (4/4) Accurately ripped
 10  | (4/4) Accurately ripped
 11  | (3/4) Accurately ripped, or (1/4) differs in 9012 samples @22:55:02-22:55:10
[AccurateRip ID: 00102a71-0091571b-920d140b] found.
Track  [  CRC  |  V2  ] Status
 01 [9281f13f|74b2638a] (00+00/27) No match
 02 [67a65937|8db88f4d] (24+04/28) Accurately ripped
 03 [7bac25bf|47c0c20c] (24+04/28) Accurately ripped
 04 [14d9f48a|287e971f] (24+04/28) Accurately ripped
 05 [2ead58ec|4a108ee7] (24+04/28) Accurately ripped
 06 [a91bde9b|c5418916] (24+04/28) Accurately ripped
 07 [8ddc9a2e|cc601eee] (24+04/28) Accurately ripped
 08 [e154a216|f4bc5ba4] (24+04/28) Accurately ripped
 09 [d4ef942d|ffe2de14] (24+04/28) Accurately ripped
 10 [eb3faa48|ca00c112] (24+04/28) Accurately ripped
 11 [2f32dd9a|a68b7934] (21+04/25) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [4BD147E7] [71A732FA]  CRC32 
 01  100.0 [385E8A08] [4FB7DFE5]  
 02  100.0 [8602C32D] [5D708A63]  
 03  100.0 [993C8D56] [C97FAF90]  
 04  100.0 [B774CE8E] [0A6F3A8E]  
 05  97.8 [6F198A5C] [05DC654E]  
 06  99.2 [4E326893] [D23F9EE2]  
 07  100.0 [24FAA82B] [DE1E478C]  
 08  99.9 [65065D09] [90AB474E]  
 09  100.0 [38D4FA51] [C72683CD]  
 10  100.0 [CA6DC859] [E97ACD95]  
 11  100.0 [A4DE95CC] [197505F2]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-19 08:35:12
There is a known bug which i forgot to fix:
Repair function needs to display a window asking confirmation and presenting you with a choice of available repair targets.
CUETools disables interactive windows when processing in batch mode, for example if you are using drag'n'drop or multi-select file browser, or if you selected a folder.
Try to select the source file in single Folder browser mode instead.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hbonded on 2012-04-19 08:58:47
Yes! Your suggestion worked! Thank you, Gregory!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-19 18:57:13
Is there any plans on getting CUETools to check against the AR v2 database also or?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-04-19 19:11:52
It does check against the ARv2 database since v2.1.2 (except limited to zero offset only).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2012-04-19 19:13:36
Is there any plans on getting CUETools to check against the AR v2 database also or?

It already does. The only thing that's missing is cross-pressing support, that is, it'll check the AR v2 database if and only if your disc is properly offset-corrected.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-19 20:49:50
It does check against the ARv2 database since v2.1.2 (except limited to zero offset only).


It already does. The only thing that's missing is cross-pressing support, that is, it'll check the AR v2 database if and only if your disc is properly offset-corrected.


Thnx for the info.

Cross-pressing support would be very nice 2 get added for sure.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-19 21:00:52
Is there a way to set where you want the ripped files from CUERipper? If it's possible so do i really wanna know how and if not so would it be a nice thing to get added.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MrMonkey on 2012-04-19 22:13:00
Quote
Is there a way to set where you want the ripped files from CUERipper? If it's possible so do i really wanna know how

Do you mean a destination directory?  If so, yes.  Just define it in the prompt under the track table.

I use
C:\Rips\%artist% - %album%\%artist% - %album%.cue
for albums with 1 discs and
C:\Rips\%artist% - %album%\Disc %discnumber%\%artist% - %album% '('Disc %discnumber%')'.cue
for albums with multiple discs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-19 22:26:33
Now i see where to do it. It have to be done manually. No folder browsing option. Must be totally blind here

Thnx MrMonkey
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-04-19 23:42:21
I use
C:\Rips\%artist% - %album%\%artist% - %album%.cue
for albums with 1 discs and
C:\Rips\%artist% - %album%\Disc %discnumber%\%artist% - %album% '('Disc %discnumber%')'.cue
for albums with multiple discs.
You could do both with a single template: (but both DISCNUMBER and TOTALDISCS required on multiple discs)

C:\Rips\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1,\Disc %discnumber%,)[' ('%unique%')']\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1, '('Disc %discnumber%')',).cue

I've added %unique% so if you rip the same disc twice it will add (1) instead of overwriting.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NiPP0 on 2012-04-19 23:51:55
Is there any way to 'update' the CUE sheet to match the current tags of the associated FLAC files without re-encoding (similar to 'correct filenames'). Since ripping I have updated/corrected quite alot of the metadata contained within the audio files.

Regards,

Ben
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-20 01:10:13
I use
C:\Rips\%artist% - %album%\%artist% - %album%.cue
for albums with 1 discs and
C:\Rips\%artist% - %album%\Disc %discnumber%\%artist% - %album% '('Disc %discnumber%')'.cue
for albums with multiple discs.
You could do both with a single template: (but both DISCNUMBER and TOTALDISCS required on multiple discs)

C:\Rips\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1,\Disc %discnumber%,)[' ('%unique%')']\%artist% - %album%$ifgreater($max(%discnumber%,%totaldiscs%),1, '('Disc %discnumber%')',).cue

I've added %unique% so if you rip the same disc twice it will add (1) instead of overwriting.


That was a very useful 'command line' korth. Thnx a lot for that 1.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Roger7 on 2012-04-21 14:54:44
Hi
CueTools is a great tool. Thanks for it
Just want CueTools to be even better.
I use now 2.1.4. Usually convert one big wav or flac file to tracks (flac files using libFlake) with separate cue.
I have a huge collections of CDs and use Logitech Media Server (LMS) with Squeezebox to listen and a tablet with android OS to navigate.
So proper tags are important for me and are used vastly by LMS to navigate, sort and so on.
For example I can click composer on a track and find which other releases of such artist I have in my collection.
I know my needs are rather not usual for most users specially with portable players.

1. A bug:
When there are less tracks in discogs database then in the image file, the "Select the best match" window shows tracks with empty track titles and the output files names are not correct.
They are like:
01 - %title%.flac
02 - %title%.flac
...
10 - %title%.flac

It happens when there are hidden track/tracks in CD and not described on the back cover/official listing and then some databases don't include these tracks in their listing, just sometimes it's mentioned in "Notes" that some tracks are hidden/untitled.
For example: Haujobb - Ninetynine (MET 113) has 10 tracks but only first 9 are in the listing on the cover and then in discogs
http://www.discogs.com/Haujobb-Ninetynine/release/16781 (http://www.discogs.com/Haujobb-Ninetynine/release/16781)
But in promo release it's described correctly with 10 tracks
http://www.discogs.com/Haujobb-Ninetynine/release/1670904 (http://www.discogs.com/Haujobb-Ninetynine/release/1670904)

2. Could be better:
When there are many artists with the same name, discogs add a unique number in parenthesis to differentiate such artists.
For example Klute (Danish electro band) is Klute (2) in discogs:
http://www.discogs.com/artist/Klute+%282%29 (http://www.discogs.com/artist/Klute+%282%29)
Then these names are written it tags and in file/folder names with this number by CueTools. I think it should be removed.

Similar thing is with artist with "The" at the beginnig of name.
For example "The Cassandra Complex"
http://www.discogs.com/Cassandra-Complex-W.../release/308322 (http://www.discogs.com/Cassandra-Complex-Work-10/release/308322)
is written in discogs as "Cassandra Complex, The".
I think that "The" should be moved at the beginning of name: "The Cassandra Complex".
It could also apply to other articles but I haven't found

I know I can change it in "Select the best match" window

3. Some more tags:
CueTools gets already barcode number but writes it only in cue sheet (as CATALOG) but not in tags. What a pity
I use UPC tag and extract the barcode from discogs description using mp3Tag regular expressions.
Discogs provides some more tags:
- for tracks:

These are tags which TagScanner uses when tagging from discogs.
There are sometimes more tags for tracks like vocals or featuring (for example when there are quest artists) and I add them to track artist besides standard track artist.
It could be nice to have them added by CueTools but I know not everyone likes this way...Maybe some option ?

- for release:


4. Separate artists:
There are releases or just tracks where there are more than one artist in ALBUM ARTIST (for a release) or ARTIST (for a track) - I don't mean VARIOUS ARTIST.
For example: Deep Forest with Peter Gabriel – While The Earth Sleeps
http://www.discogs.com/Deep-Forest-With-Pe...release/1600968 (http://www.discogs.com/Deep-Forest-With-Peter-Gabriel-While-The-Earth-Sleeps/release/1600968)
"Deep Forest" and "Peter Gabriel" are different artists and they are linked separately in these discogs release.
It could be written in separate tags: two (in these case) ALBUM ARTIST tags for release and two ARTIST tags for such tracks.
Or it could be written in one tag with a separator. I use "; ". So for me it's ALBUM ARTIST="Deep Forest; Peter Gabriel" and for track 1 and 3 ARTIST="Deep Forest; Peter Gabriel".
But I'm afraid it's could be hardware/software depended to read such tags...

5. Tags mapping:
It could be a nice feature to be able to configure how to write some non standards information(fields) to tags.
For example fields like: labelno, releasecountry, release date (why isn't it releasedate as previous?  ), barcode...
As I know it's format depended (different for flac, mp3, ape) but my knowledge is poor...
So it could be a table:
field/tag | FLAC | MP3 | APE
field1    | tag1  |  ...  | ...
field2    | tag2  |  ...  | ...

In each cell (for a specified format and field) you can choose: <default>, <blank>, choose from a list of other tags or write your own custom tag name.
Where:
<default> - default CueTools tag
<blank> - field is not written to tag
But I know it's complex.

Once again thank you for a great piece of software.
It's not a criticism just want to present some my ideas to make a CueTools an ultimate tool.
You can use it or just forget it

Best regards
Roger
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2012-04-22 03:06:33
What happened to "whole album" check concept? I see that now it is just gives results per track, just like Accurip. I thought that that was not even possible.

What differences between CTDB and AR are left?

Is it still possible to have this in the new logs:

[CTDB TOCID: B95jzBQTLVkXdF9exkf4KxYAAwQ-] found.
        [ CTDBID ] Status
        [9af9f5f3] (304/304) Accurately ripped

I liked it, and I used it in my scripts.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-04-22 03:25:36
Is it still possible to have this in the new logs:

[CTDB TOCID: B95jzBQTLVkXdF9exkf4KxYAAwQ-] found.
        [ CTDBID ] Status
        [9af9f5f3] (304/304) Accurately ripped

I liked it, and I used it in my scripts.

CUETools 2.1.4: Advanced Settings -> Advanced -> CTDB -> Detailed log = True
CUERipper 2.1.4: Options -> CTDB -> Detailed log = True

Also, I've written a page on the new log here (http://www.cuetools.net/wiki/CUETools_log).
I'm going to start on 'settings' pages next.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2012-04-22 11:59:43
CueTools is a great tool. Thanks for it
Just want CueTools to be even better.
I use now 2.1.4. Usually convert one big wav or flac file to tracks (flac files using libFlake) with separate cue.
I have a huge collections of CDs and use Logitech Media Server (LMS) with Squeezebox to listen and a tablet with android OS to navigate.
So proper tags are important for me and are used vastly by LMS to navigate, sort and so on.


(I have added bold to referencing to TAGS, I hope this helps reading and not makes my post look like an annoying cheetah, LOL)

Interesting, detailed post. Just adding my thoughts about some things you mentioned. If you use FLAC files exclusively then all is OK for you, and by normal standards, I don't believe that WAV files are to have any kind of tagging data (though AIFF, Apple's version of WAV can). Personally, I use FLAC files as well, and I also embed CUE files, but I was thinking CATALOG was written? Maybe I am wrong, it's very possible. Maybe very likely, haha... but when comparing the tagging of FLAC files vs. using ID3 tags for MP3's, or Apple's "atom" format tagging of MP4 container files (M4A)... they're quite different. For FLAC files, I know this much...

There is a structure of about 8 parts complete that FLAC files are built using. The very first is a STREAM INFO header (please, no need to correct and be exact on that, I'm demonstrating only the concept that's important)... then we have 1-2 more... then we have a VORBIS COMMENT block, in which our tagging goes for the tracks. After that, we have a separate CUESHEET block, which holds the obvious... then an ART block (or can be several instances for front, back, extra covers)... finally, we have the actual stream of audio data block. I skipped a few that I do not recall off of the top of my head, but the important idea I'm making is that the VORBIS COMMENT, CUESHEET, and ARTWORK are all contained in separated "blocks". Unfortunately, I do not know what goes on inside of the VORBIS COMMENT block... what is allowed and what is not, etc. You may know this detail since it appears you have studied into things, as well.

We know in a typical "bare-bones" CUE sheet, we will have a few things:
REM GENRE
REM DATE
REM COMMENT
(usually EAC or the encoder will put their info here)
REM DISCID (CDDB database hash, 8 hexadecimal positions)
CATALOG (usually pulled from the CD-TEXT it most times matches the UPC for USA, or EAN for Europe; as you said: your BARCODE)
PERFORMER
TITLE
FILE
  TRACK...


I won't go further, this is just for skeleton outline. What I don't understand, Roger7... is why these first few items are so non-standard or in other words, they don't follow logical rules. For specifics:
Even though GENRE is technically only a REM (remark) line, it is embedded to file tags. Same is true of date/year. Comment? I think it's left out. DISCID is left out, I believe...  and you say that CATALOG is left out, as well... even though it is *not* a REM line, and seems (logically) as it should be included, right? But even still, REM's are selectively added, not as a standard/uniform practice.

Other info we have extra that is non-structure related are ISRC codes for each track, and sometimes we get FLAGS DCP for copy protection which are safely removed.

Are we leaving out DISCID because we have no standardized field for this? CATALOG I felt pretty sure is a standard field.

Just for further note, when I'm in the process of ripping new CD's I may add, also in the CUE file, I add even further non-standard things. Mine, I add these lines to the CUE file:

REM LABEL
REM LABELCAT


Eh, those are all I can recall off hand, but I believe this sh... whoops said sh1t accidentally!!! hahahah... this SHOULD map LABEL->PUBLISHER and as far as I know there is no field for internal catalog for the label. Can you or anyone let me know if there is such a field? To make specific, CATALOG is maybe 00934923848123 (imagine the 12 or 13 digits or whatever lol)... which I consider to be CATALOG/UPC/EAN/BARCODE... now we always have with the label an internal catalog number as well, you see this as maybe I'll make up "TN23" for Tooth & Nail Records, 23rd release is usually the standard. Another typical example is "392943-2". What do we do with this catalog? It is valid for internal use just as much as the barcode... as is the LABEL important. If I were to change this to REM PUBLISHER would it add the tag? I figure the answer is no. It would be nicest if for any entry we have here, we get the name mapped to the identically named tag... so if I put say... REM FOO BlahBlahBlah -- then it would write a tag named "FOO" with value of "BlahBlahBlah". In my perfect world, at least haha...

I want to ask this, do you or anyone else know if there is a way to embed any more information than GENRE, DATE, and... that's it I suppose? Are there ones like this that are real? (I've seen them but I have never known them to embed), according to tagging documents I have the correct tags are:

REM DISCNUMBER 1
REM TOTALDISCS 1
REM TOTALTRACKS 12
REM PUBLISHER Atlantic
or for two tokens, REM PUBLISHER "Atlantic Records"

Any way to embed any of these? Do I remove the REM, leave it, or it's just simply impossible to do without manual work? It's not huge work to add these, since I manually add artwork and sometimes certain tags for special types of music like remixes, multiple artists on a track, and this type of thing.

I need to know any secrets of the CUE file that I have not unlocked, LOL.

Oh, I'm sorry and my original point was that I know there is other threads discussing that FLAC uses ALBUMARTIST tag while ID3 uses ALBUM ARTIST tag -- but foobar2000's newest versions remedy this issue by making the correct tagging transparent to the users.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 2012-04-22 12:01:44
Oh, I'm sorry to post again, but this would be lost in my post above and never seen. Just trying to be helpful!

This is just a friendly reminder to update the SUBJECT of the thread to reflect the true current version 2.1.4, right now it is showing incorrectly the old one.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2012-04-22 15:05:42
Sorry, i haven't got around to this yet.

UPD: tried to reproduce it, but couldn't. In theory this can only happen if takc.exe crashes on startup.

Indeed, you couldn't reproduce it because it's a bug in TAK, and not in CUETools. I feel very stupid for not having realized it previously. It is caused by the fact that TAK does not have support for Unicode file names.

Sorry for wasting your time.

By the way, I'm really diggin' the new AR logs. Way to go.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Isayama on 2012-04-22 16:12:19
Thanks again Korth.  I'm only up to page 9 so far!  Trying to take it all in rather than skim.

As I understand it, by doing at least 2 passes it is already doing test and copy.  The log file shows both CRCs anyway.

Hi everyone,

First of all, I'd like to thank Gregory S. Chudov for the great tools CUETools and CUERipper are. I'm using them with much satisfaction, especially because of the improved ripping speed compared to EAC, and also for the simplicity of their configuration ("best options" --if following HA lossless rip guide-- automatically chosen, etc.). I hope they'll become the preferred softwares when it comes to high quality encodes and verification.

Since the upgrade to version 2.1.4 though, I have a question concerning the "test and copy" feature: what is meant by
Please welcome, CUETools v2.1.4.

16.04.2012: CUETools 2.1.4:
* CUERipper: real test&copy mode
?
I've been looking at my log files from rips made with 2.1.2a: they display both Read and Copy CRCs. And then in 2.1.4, I've checked and then unchecked the new "Test and copy" box: it turned out that with the box checked, both CRC values were still present, but encoding took quite a lot more time; but when unchecked the log file only contained Copy CRCs.

Does that mean that on all my rips done with the previous version of CUERipper, no "test and copy" operation was performed, and the log was just mocking the option? (I'm sorry if it has already been discussed in this thread, I've browsed it up to page 30 but it's really vast and everything doesn't necessarily concern me...)

[off topic] Btw, would it be possible to create a dedicated topic in HA forums for CUETools/Ripper, so that questions could be addressed in separate threads and people wouldn't have to browse the whole one here? I assume it could reduce the number of duplicate questions...[/off topic]

Or did 2.1.2a always performed T&C without leaving the choice, and that's why you added a "real test and copy mode", so that it'd be a mode. But in that case, why ripping would take so longer with the new version? I remember reading here:
As I understand it, by doing at least 2 passes it is already doing test and copy. The log file shows both CRCs anyway.
So what does it mean?

Thanks again for your tools, I hope development will pursue the excellent work.

Best regards
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-22 17:32:35
CUERipper always does at least two passes in secure mode. If results from those two passes differ, or the drive reports C2 errors, it does more passes, and the error correction progress bar lights up. If the problem persists, it eventually marks suspicious positions in the log file. But it is not collecting separate CRCs for those passes, because some parts of a track can be read twice while other parts can be read many times.

So before version 2.1.4 it just printed the same CRC twice. It was pointed out to me that this is misleading, because some people actually like to compare CRCs with their own eyes, so 2.1.4 just prints one CRC unless you check 'Test & Copy', in which case it now collects two sets of CRCs by reading the whole CD twice, doing at least two passes each time, so every sector is read at least 4 times.

I personally find this an overkill, but that's what many people are used to. Personally, i just use default settings (secure mode, no test&copy), or if i expect problems ripping a certain CD and don't mind waiting a bit longer, i use Paranoid mode (which reads every sector at least 3 times). This is usually faster than test&copy in secure mode, but has a better chance of doing a perfect rip.

Unlike Paranoid mode, Test&Copy doesn't increase your chances of getting an accurate rip, so i guess the only reason it is so popular is that you can see two sets of CRCs with your own eyes and compare them yourself, instead of trusting the ripper to compare each bit of data from several passes and print out the suspicious positions.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-04-23 03:27:24
CUERipper: There still appears to be a problem with EAC style rip log in Paranoid mode.
Just tested Burst mode. Everything was fine. Switched to Paranoid mode, rip was fine, rip log says Burst mode. Even the wav file locations show the folder for previous Burst rip. Restarted CUERipper. Switched to Paranoid mode, rip was fine, rip log says Secure mode. File locations correct.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Isayama on 2012-04-23 11:17:47
I personally find this an overkill, but that's what many people are used to. Personally, i just use default settings (secure mode, no test&copy),...

Thanks a lot, that's exactly the kind of precisions I was waiting for. This does clarify the process and the changes made. Now this question's been figured out, I can resume ripping my CDs without wondering   

Cheers
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2012-04-24 06:56:38
Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-24 10:35:11
Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.


'Test & Copy' works just fine here. Have made like 4-5 rips with it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-24 16:57:24
What about getting a 'Medium' option for 'Album art search'. There is only Small and Large available now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-24 18:07:21
CUERipper is not using Google to search images. It uses artwork from Musicbrainz & Discogs, and there are only full size pictures and thumbnails in those databases. However i will consider implementing custom image sizes by downloading full size images, than shrinking them to desired size.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-24 20:05:46
CUERipper is not using Google to search images. It uses artwork from Musicbrainz & Discogs, and there are only full size pictures and thumbnails in those databases. However i will consider implementing custom image sizes by downloading full size images, than shrinking them to desired size.


Thnx for the reply/info Gregory.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-04-25 03:18:58
Just noticed that the embedded cover art gets added twice.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2012-04-25 04:42:08
'Test & Copy' works just fine here. Have made like 4-5 rips with it.


Very strange problem. I still can't figure out why it's giving me that Exception error. Test & Copy is merely a switch that tells CUERipper to start the ripping process over again after the first cycle is complete. There doesn't seem to be any reason why it would make a difference whether or not I have the switch engaged. Odd.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2012-04-26 01:57:13
1. I thought that the confidence results are only based on actual rips, but after I verify an rip not present in CTDB with CUETools, next time will have confidence 1. Can you please explain?

2. I got quite a few errors like this:

Code: [Select]
.\Joss Stone - 2005-07-08 - Mind Body & Soul\Joss Stone - 2005-07-08 - Mind Body & Soul.cue: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index.


And the accurip log reads:

Code: [Select]
[CUETools log; Date: 4/25/2012 8:54:01 PM; Version: 2.1.4]
[CTDB TOCID: YDhmfif05xgrPtNh8.pN4sFhCp8-] found.
        [ CTDBID ] Status
        [eb466f8b] (25/48) Accurately ripped
        [0dd4fda1] (01/48) No match


Is it accurate or not? And why is the log looking like that?

Edit: that's the whole log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-26 10:01:45
1. I haven't disabled CUETools submissions yet, so for CDs that are not yet present in the database any rip with AR confidence >= 2 can be submitted, and will have CTDB confidence == 1 (AR confidence is ignored, but CTDB confidence cannot be zero). Only results with CTDB confidence >= 2 can be considered reliable, which means that CTDB no longer trusts AR, but AR-verified rips need only one independent rip to be confirmed and receive CTDB confidence == 2.

2. Thanks, found a bug in the code that produces detailed CTDB log. This happens when CD has a data track. My advice is turn detailed CTDB log off until i make a hotfix. This option is off by default, so most users don't need to worry.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2012-04-26 17:38:31
Code: [Select]
 Index was out of range. Must be non-negative and less than the size of the collection.


So this means that the CD has a data track, it could be a perfectly good rip, but it cannot be verified. Is that correct?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-04-26 19:06:43
Yep. It is perfectly verified. "(25/48) Accurately ripped". Just turn off the detailed option of the log, the standard one is easier to read.
Also refer to this: http://www.cuetools.net/wiki/CUETools_log (http://www.cuetools.net/wiki/CUETools_log)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radu on 2012-04-28 00:33:03
Yep. It is perfectly verified. "(25/48) Accurately ripped". Just turn off the detailed option of the log, the standard one is easier to read.
Also refer to this: http://www.cuetools.net/wiki/CUETools_log (http://www.cuetools.net/wiki/CUETools_log)


Now  I got it. I only have that message and the weird log when I use the detailed option.


I want to thank you for all your work you put in the development of CT, I really appreciate it. It is one of the few applications I install the first day I have a new OS.

Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2012-04-30 07:00:03
Hey folks,

I have two questions.

1. Is there any way to make CUETools transfer tags 1:1 on conversion? Whenever I convert files, the full value for %date& is truncated. For instance "1995-11-20" is only "1995" after conversion.

2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?

Thanks!

:-)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-04-30 13:36:22
Quote
1. Is there any way to make CUETools transfer tags 1:1 on conversion? Whenever I convert files, the full value for %date& is truncated. For instance "1995-11-20" is only "1995" after conversion.
CUETools is getting that info from your cue file or online database. Does your cue file have 1995-11-20?
Quote
2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?
Untick 'to nearest' in Advanced Options on the AccurateRip tab.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2012-04-30 13:58:27
2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?


Why would anyone want to do this? This whole process is to make an accurate copy of your CD. So, you want to go through the trouble of creating an accurate copy and in the final step convert it into an inaccurate copy?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2012-05-01 11:00:31
CUETools is getting that info from your cue file or online database. Does your cue file have 1995-11-20?

Yes. I have all my music stored as FLAC images where the CUE sheets are embedded though.
The embedded CUE sheet has the value as shown here: "REM DATE 1995-11-20".
I've made some tests with different settings in the tagging menu.
However either the date is truncated, or it is copied completely - but then the disc number info is missing.

Untick 'to nearest' in Advanced Options on the AccurateRip tab.

Thanks! :-)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-01 15:30:23
The embedded CUE sheet has the value as shown here: "REM DATE 1995-11-20".
OK that helps a little. Using the embedded cue only, it does appear that CUETools reads the date correctly, will use it as %DATE% everywhere else (templates, cue, embedded cue) but does not write it to the tags if split into tracks (date is blank if more than 4 digits). So if you're converting to tracks, I won't be able to help with settings unless Gregory wants to change this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mthomas1 on 2012-05-01 18:10:45
I've been an EAC user and recently started working with CUERipper. I really like the speed of the ripper. One downside, however, is the metadata. I really like having access to the GD3 database in EAC. I find it often has CDs that aren't in musicbrainz and the quality of the metadata (especially the higher res images) seems better. Andre seems to have worked out a really cheap lifetime license for EAC users to get access to GD3. Do you think it would be possible to add this to CUERipper?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-05-03 23:02:39
I'm not sure about obtaining cheap lifetime licenses, but it shouldn't be difficult to add support for GD3 to CUERipper for users who purchase their your own licenses.

On the other hand, i'm not sure i want to promote proprietary solution when we have decent open alternatives, i would rather work on improving integration with musicbrainz.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-05-04 11:16:21
When using 'EAC style log' in CUERipper, should it not say 'CUERipper extraction log' on the 2nd row of the log instead of 'EAC extraction log'?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-04 13:07:51
Does it not say 'CUERipper' on the top line of the page? Everything below that mimics the EAC logfile and should tell us so.
'EAC-style extraction logfile' maybe.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-05-04 13:27:59
Just because the option say 'EAC style log' doesn't mean it have to say EAC in a CUERipper log or?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-04 14:53:50
Make more sense than having two completely different looking log files titled and named exactly the same.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2012-05-04 16:05:49
Windows 7 Home Premium 64-bit

1.
I use CueTools Drag 'n' Drop Mode.I like the wide window which more easily shows the results and summary line after a Verify operation.

I created Windows "Send To" shortcut so I can right-click a .cue sheet to have it automatically open in CueTools, ready to Verify. However, when CueTools launches this way, it is not in Drag 'n' Drop Mode. Instead, it opens as a tall, narrow window that seems to be Hide Browser mode. I am unable to make that window wider, which makes it awkward to read Verify results.

Q1.
How to make CueTools always launch in Drag 'n' Drop Mode, even when it launches by a file being sent to it via a Send To shortcut?
Are there settings I can change to do this, or some command string or batch file that could launch CueTools with some switches or parameters?


2.
Drag 'n' Drop Mode shows a nice summary of the Verify results,
e.g. AR: rip accurate (41/41), CTDB: verified OK, confidence 41,
but it does not show the full .accurip results in the CueTools window. Other modes show full full .accurip results but do not include the nice summary statement.

Q2.
Is there a way to have CueTools display both the summary line and the full results after a Verify?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-04 16:43:56
1. No. CUETools will currently only open in 'Hide browser' mode when launched this way.

2. No. Batch modes like Drag'N'Drop and Multiselect browser can process many discs in a row, thus the single line summary. Detailed results are shown when only one disc can be processed (Folder browser mode with a single file or file grouping selected).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2012-05-04 18:34:25
Thanks for the reply.

Re. 1., can we make a suggestion that a future release incorporate a way to launch into a preferred mode, so that we could use a "Send To" shortcut to open CueTools in Drag 'n' Drop Mode (for users who prefer that mode)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-05-04 18:35:39
Maybe
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2012-05-04 18:59:34


"Maybe" is a promising reply. Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-08 00:49:11
Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.
I can confirm this error.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2012-05-10 01:51:02
I can confirm this error.


It's good to see at least one person here is willing to address this problem.

I've found one drive that doesn't give off the error when using Test & Copy mode. However, three others do. The problem occurs in both internal and external (USB) configurations.

Again, I cannot think of any logical reason why all three drives work fine in single-pass mode mode, yet gap detection fails when 'Test & Copy' is chosen. It's an annoying bug, to say the least.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-05-10 02:29:20
Don't worry, it's on my list.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-05-16 07:31:01
https://plus.google.com/1044831631470493086...sts/8ifVBgVbkvJ (https://plus.google.com/104483163147049308670/posts/8ifVBgVbkvJ)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: anson5 on 2012-05-18 17:47:48
I'm using CUETools 2.1.4 on Windows 7 Home Premium SP1 x64.

I have ripped a set of 4 CDs as 4 flac files with EAC 1.0 beta 3.  They are from the same CD set so I combined the cue files into one and renumbered the tracks in it.  When I clicked the "Go" button to encode (to any output format), it gave me the following exception right away:

Code: [Select]
  crc.Combine length cannot be negative
  Parameter name: len2

I then tried the 4 original cue files individually and they all worked fine.  I ended up found out that I need to remove the cue of the 4th CD and it would work.  I then tried a different set of 4 CDs, which have more tracks on each CD (i.e. longer audio length on each CD).  On this different set, I need to remove the cue of both 3rd and 4th CDs for it to not throw the aforementioned exception.

So it looks like there is a threshold of combined audio length for a single cue file in CUETools 2.1.4; when this threshold is exceeded, CUETools will result in a negative combined CRC and the exception will be thrown.

Is there any workaround for this issue?  Using a combined cue file for multi CD set can save a lot of time with regards to file naming and tag data for each track.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-18 22:33:58
Quote
I then tried the 4 original cue files individually and they all worked fine.
CUETools is working correctly as it was designed to process a single redbook CD rip at a time, not compilations containing multiple discs.
Quote
Is there any workaround for this issue?
Not a CUETools issue. The input is not correct.
Quote
Using a combined cue file for multi CD set can save a lot of time with regards to file naming and tag data for each track.
Metadata lookups are based on the CD TOC of one disc.

Batch mode may be what you're looking for but I can't tell what you were trying to do.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: anson5 on 2012-05-19 07:23:43
CUETools is working correctly as it was designed to process a single redbook CD rip at a time, not compilations containing multiple discs.  Not a CUETools issue. The input is not correct.

But a single cue file containing multiple FILE commands is still a valid CUE sheet.

I read someone else having the same error in this thread but there was further explanation.

Honestly, I combined the CUE files because then the output file names (%tracknumber% %artist% - %title%) are numbered correctly, rather than 4 files starting with "01", 4 files starting with "02", and so on.  This also applies to the track number tag as well; I want 1/72, 2/72, etc. in stead of 4 files with 1/18, and so on.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2012-05-19 08:17:31
So it looks like there is a threshold of combined audio length for a single cue file in CUETools 2.1.4; when this threshold is exceeded, CUETools will result in a negative combined CRC and the exception will be thrown.
Probably 79.8 min, i.e. the maximal length allowed by the Red Book standard (http://en.wikipedia.org/wiki/Red_Book_(CD_standard)).

Quote
Is there any workaround for this issue?  Using a combined cue file for multi CD set can save a lot of time with regards to file naming and tag data for each track.
I guess there isn’t. The customary solution recommended for a scenario like this is to use a format that is actually designed for organising and tagging files of arbitrary formats, metadata, lengths, etc., which a cue-sheet is not.

I, too, think it would be quite nice if the ‘standard’ could be extended, revised, or allowed more frequently to diverge from whatever guidelines are being followed by programmers; but no developer (at any point between ripping and playback) is under any obligation to implement it in any other way than is required for its primary purpose. And that’s to represent the ToC of a Red Book audio CD, with any CD-Text and other subcode-based metadata that the user might choose to include.

This could take us back to the old argument about whether things outside the standard should just be allowed/ignored when they can’t really have any adverse effects, but rather than starting that, why not keep it simple and see what Gregory thinks?

But a single cue file containing multiple FILE commands is still a valid CUE sheet.
Not relevant!

Quote
Honestly, I combined the CUE files because then the output file names (%tracknumber% %artist% - %title%) are numbered correctly, rather than 4 files starting with "01", 4 files starting with "02", and so on.  This also applies to the track number tag as well; I want 1/72, 2/72, etc. in stead of 4 files with 1/18, and so on.
Is it literally as simple as each disc having 18 tracks? Then you could probably fudge together some code for this set, e.g.:
Code: [Select]
$add(%tracknumber%,$mult($sub(%discnumber%,1),18))
[/s] [Edit: ignore that, seeing as I was referring to foobar2000’s title-formatting rather than CUETools’s; d’oh)][/color] Alternatively, avoiding clashes in numerical sorting is always made simplest by including the disc number before the tracknumber, but I presume you have already discounted this option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-19 14:50:34
But a single cue file containing multiple FILE commands is still a valid CUE sheet.
Not a valid CD cue sheet if the contents won't fit on a single CD.
Quote
I read someone else having the same error in this thread but there was further explanation.
Looks like question was asked, but I didn't find where it was ever answered.
Quote
Honestly, I combined the CUE files because then the output file names (%tracknumber% %artist% - %title%) are numbered correctly, rather than 4 files starting with "01", 4 files starting with "02", and so on.  This also applies to the track number tag as well; I want 1/72, 2/72, etc. in stead of 4 files with 1/18, and so on.
The get this result you could process the 4 discs individually in CUETools then do the rest in Foobar2000 using Properties>Tools>Auto Track Number and File Operations>Rename To. You would have to load files in the correct order or use a combined playlist file (not cue sheets) and all files would need to be in the same folder.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2012-05-19 18:36:25
Is it possible to convert where the original .cue is? What do I have to insert on Template?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-19 19:08:37
[%directoryname%\]%filename%-new[%unique%].cue
-new[%unique%] is there so you don't overwrite the original cue.
or
[%directoryname%\]%artist% - %album%[' ('%unique%')'].cue
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MourningStar on 2012-05-20 01:03:54
I tried search for term "slider" and was trying to pin it to this forum only but results were not helpful so ...

can someone please explain to me for CUETools the slider function in the last column of the main window? or point me to a tutorial where it is explaned? The app fires up with it set to 5 (the range is 0 to 8).

thank you
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-20 01:32:38
I tried search for term "slider" and was trying to pin it to this forum only but results were not helpful so ...

can someone please explain to me for CUETools the slider function in the last column of the main window? or point me to a tutorial where it is explaned? The app fires up with it set to 5 (the range is 0 to 8).

http://www.cuetools.net/wiki/CUETools_FLAC...ders_comparison (http://www.cuetools.net/wiki/CUETools_FLAC_encoders_comparison)
Slide to the desired mode or compression level. For lossless codecs this doesn't affect quality, higher modes normally produce smaller files, but extraction can be slower. For lossy codecs, higher modes normally produce larger files with better audio quality.
I'll be working on a page that explains the settings in the main window next similar to what I'm working on for CUERipper (http://www.cuetools.net/wiki/CUERipper_Settings) and CUETools Advanced Settings (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools) pages. All pages aren't finished yet. A couple tutorials will follow referencing these pages.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MourningStar on 2012-05-20 01:46:19
thank you korth for a most informative and prompt reply.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2012-05-20 14:29:59
CUETools creates a dummy-cue while converting if there is no cue to begin with, and also does so using the "Create CUE Sheet" action. It uses gap information from the log if present too, but it doesn't write a REM DISCID. IIRC, you only need to know the TOC in order to calculate the CDDB1 DISCID, and the TOC is always present in newer EAC logs.
Is it possible to also write the DISCID to the cue sheet? I couldn't find an option for this. And if it's not, could it be added in a future version? Or is there maybe a reason for not including it? Since I can't quite imagine this has been forgotten.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-20 16:41:34
you only need to know the TOC in order to calculate the CDDB1 DISCID, and the TOC is always present in newer EAC logs.
It's also being calculated using the TOC of the files being processed as it is the 3rd part of the AccurateRipID: xxxxxxxx-xxxxxxxx-DISCID
EDIT: To see the TOC used when processing files you can turn on the Create TOC (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#Misc) option which will create a text file with the same filename as the output CUE and the extention .TOC
Quote
Is it possible to also write the DISCID to the cue sheet? I couldn't find an option for this. And if it's not, could it be added in a future version? Or is there maybe a reason for not including it? Since I can't quite imagine this has been forgotten.
I believe this is part of Moitah's original code so probably something not changed much by Gregory. No option found here either.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2012-05-20 21:52:52
It's also being calculated using the TOC of the files being processed as it is the 3rd part of the AccurateRipID: xxxxxxxx-xxxxxxxx-DISCID
EDIT: To see the TOC used when processing files you can turn on the Create TOC (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#Misc) option which will create a text file with the same filename as the output CUE and the extention .TOC
Ah yes, that's right.

However, for discs with CD-Extra content, the incorrect ID would be calculated, right? It can't handle sheets pointing to BINARY files, it seems. And of course, it doesn't process data tracks themselves. So it's safer to use the TOC from the EAC log (provided that the CRCs match (?)), since it has the TOC straight from the original disc. It does so already when verifying, I think.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-05-20 22:50:56
Quote
However, for discs with CD-Extra content, the incorrect ID would be calculated, right?
If the wrong ID was calculated then the wrong AccurateRipID would be used by CUETools for verifying. The CTDB TOCID stores the CD-Extra info separate.
Quote
It can't handle sheets pointing to BINARY files, it seems. And of course, it doesn't process data tracks themselves. So it's safer to use the TOC from the EAC log (provided that the CRCs match (?)), since it has the TOC straight from the original disc. It does so already when verifying, I think.
If you had the EAC log in the same folder as the source files and the DISCID was missing from the cue, CUETools would parse the log for the TOC then (if found) for any CD-Extra content (an additional track) and adjust the TOC used to calculate IDs used for the lookups. The resulting TOC file would look just like the TOC in the log. Note: The EAC log should have the same filename as the CUE for best results (especially in batch modes where you aren't prompted).

If the DISCID was missing from the CUE and TOC was missing from the LOG but you knew the data track length in mm:ss:ff, you could enter it in the Extra section under Data Track. CUETools would adjust the TOC and IDs used for lookups and the resulting TOC file would include the CD-Extra content (an additional track).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Henglander on 2012-05-26 15:01:35
You can always download the latest source code from project's SVN repository (http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/) at SourceForge.
Instructions for svn access can be found here (https://sourceforge.net/svn/?group_id=242216).


Unfortunately it doesn't build (Debug Any CPU - 4 failed) because some stuff is missing from my machine. The later fails may be a result of the first.

36>PreBuildEvent:
36>  C:\work\cuda\bin\nvcc C:\Users\xxxx\Documents\Visual Studio 2010\cuetoolsnet\trunk\CUETools.Codecs.FlaCuda\flacuda.cu  -o C:\Users\xxxx\Documents\Visual Studio 2010\cuetoolsnet\trunk\CUETools.Codecs.FlaCuda\\flacuda.cubin --machine 32 --cubin --compiler-bindir "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin" --system-include "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include"
36>  The system cannot find the path specified.


39>ResolveAssemblyReferences:
39>  Primary reference "CUETools.Codecs.FLAC".
39>      Could not find dependent files. Expected file "C:\Users\xxxx\Documents\Visual Studio 2010\cuetoolsnet\trunk\CUETools\..\bin\Debug\plugins (Win32)\CUETools.Codecs.FLAC.dll" does not exist.

41>ResolveAssemblyReferences:
41>  Primary reference "taglib-sharp".
41>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3245: Could not resolve this reference. Could not locate the assembly "taglib-sharp". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

56>ResolveAssemblyReferences:
56>  Primary reference "CUETools.Codecs.FlaCuda".
56>      Could not find dependent files. Expected file "C:\Users\xxxx\Documents\Visual Studio 2010\cuetoolsnet\trunk\bin\Debug\plugins\CUETools.Codecs.FlaCuda.dll" does not exist.

How do I need to configure the machine to get it to build?

H
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-05-26 16:39:34
1) Just unload the project CUETools.Codecs.FlaCuda, it is not supposed to build. FlaCuda is replaced by FLACCL, i just didn't remove it from solution yet.
2) Try to build Release instead of Debug, some projects might not be configured correctly for debug build, for example taglib-sharp has wrong output path in Debug mode (should be ..\..\bin\Debug\)
3) Projects under 'Plugins/Native codecs' don't support 'Any CPU' platform and should be built twice, for 'Win32' and 'x64'. You might need to have both VS2005 and VS2008 installed to build them. FLAC also requires nasmw.
4) You can also just ignore 'Plugins/Native codecs' - they are difficult to be build, rarely change and CUETools works without them. If you do need ape/wv plugins, you can use binaries from 2.1.4.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Henglander on 2012-06-07 12:08:56
... You might need to have both VS2005 and VS2008 installed to build them. FLAC also requires nasmw...

Thanks I have managed to get it all to build, including FLAC, although I use vs2010. Apparently nasmw is now called nasm.

Now, a question to how it works. Possibly, this belongs in a different thread so feel free to relocate this.

How does cuetools work out whether it can repair (and where does it do that) and how does it decide to or not to repair?

I have a couple of rips where one track is aweful - the rest are great. CUEtools says the confidence for the good tracks is 8/8 and that of the bad track is 1/8. My thinking is that 7/8 agree that that one track is bad, although they might not agree why. If the 7/8 also agree what is good then because they all agree about the other tracks one can safely say (7/8) that one track needs repairing and repair it.

Currently cuetools will not repair that one track. I do not know why, possibly because of the 1/8 confidence that it is ok. So I was looking for a place in the code where I could apply that well known statistical law "One is None" to the confidence level.

Do you have any pointers fro me?
H.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-07 13:43:28
Is this CTDB confidence or AccurateRip confidence? Confidence levels should be 2 or higher before you should consider them reliable.
The disc has to have repair data stored in the CUETools Database (http://www.cuetools.net/wiki/CUETools_Database) (CTDB) and has to differ from the content of your disc. There are known issues (http://www.cuetools.net/wiki/CUETools#Known_issues) using 'repair' when more than one entry is in the CTDB. Some help with the log can be found here (http://www.cuetools.net/wiki/CUETools_log). The repair function is a custom script (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Scripts) so not really part of the source.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d3m0n1q_733rz on 2012-06-08 09:18:28
Hey, I was wondering if we could get a wiki as far as instructions of how to tell if an offset is accurate and how to fix it, best practices, etc?  Some things such as offsets are unclear as to whether or not they've been correctly detected and accounted for, or if further correction needs to be taken to counter offsets.  For example, if it says that it has an offset of 6, does one enter 6 into the offset correction box and tell it to fix offset or do they enter -6 to bring it back to 0?  And if some data is lost from the beginning by utilizing the wrong offset, can a repair be made to recover the correct data so none is lost?
If anyone who fully understands the program is willing, I think an online instruction manual would be awesome for the site!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-08 14:20:35
I'm working on wiki pages for the site with plans to include a few guides and a Q&A page. Still need to finish the program setting pages for reference. Hopeful others will jump in with additional guides and a few custom scripts.

There's really no reason to change the offset of the files and to do so is at the risk of data loss. Cross-pressing verification is there for just that...verification. If your disc was ripped with the proper offset correction then the offset is correct even if that offset isn't in the AR database. If it wasn't ripped with the proper offset correction and you don't know the offset correction for the drive used, then you're just guessing.

Unless your drive is overread capable, samples can be lost even when offset correction is applied properly. The lost samples are usually padded with zeroes by the ripping program. Both AR and CTDB account for this by ignoring samples at the beginning and end of each disc. The repair data also excludes these samples so any data lost in this area cannot be repaired.

EDIT:
Quote
For example, if it says that it has an offset of 6, does one enter 6 into the offset correction box and tell it to fix offset or do they enter -6 to bring it back to 0?
It doesn't hurt your files to use the Extra:Offset box to Verify your rip. If it says 6 then enter 6. If it says -6 then enter -6. This is actually the only way to see ARv2 entries at other offsets.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2012-06-08 20:09:39
It doesn't hurt your files to use the Extra:Offset box to Verify your rip. If it says 6 then enter 6. If it says -6 then enter -6. This is actually the only way to see ARv2 entries at other offsets.


When you say "If it says -6 then enter -6", what is "it"? Does that refer to the Read offset correction used on the ripping drive?

I normally rip using EAC, and have "Read offset correction" properly detected and set. For those rips that don't immediately show an AR match in the rip log, I like to use CueTools to Verify. I'd love to also be able to check against ARv2 entries at other offsets.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-08 23:34:33
I made the assumption the OP was referring to CUETools, with "it" being the CUETools Verify Log and correcting the offset when results came back non-zero. So my answer is based on that assumption. I agree after rereading the question that the OP could have meant something else and should've asked for clarification.

Quote
For those rips that don't immediately show an AR match in the rip log, I like to use CueTools to Verify. I'd love to also be able to check against ARv2 entries at other offsets.
When you don't see results in the verify log except at another offset "Offsetted by xxx:" and tracks show "No match (V2 was not tested)" in 2.1.4 or "No match but offset" in 2.1.2a then there's a chance of ARv2 entries (see notes below). You can enter the value xxx in the Extra:Offset box and verify again to see if the ARv2 entries exist.

Note1: "No match (V2 was not tested)" and "No match but offset" can also indicate a partial match or alternate mastering which still means "No Match".
Note2: Even if all tracks show ARv1 entries at another offset there can still be ARv2 entries that weren't tested.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: agressiv on 2012-06-09 22:18:42
Is there a way of suppressing the modal popup "done" when finishing an encode?  I couldn't find it anywhere in the graphical settings and didn't want to try hacking around the settings.txt file.

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-10 02:29:29
Don't think so but then I'm still trying to remember ever seeing that popup in CUETools. CUERipper has that kind of popup when it finishes ripping and I don't know of any setting to suppress that one.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fadsplat on 2012-06-10 13:44:01
I made the assumption the OP was referring to CUETools, with "it" being the CUETools Verify Log and correcting the offset when results came back non-zero. So my answer is based on that assumption. I agree after rereading the question that the OP could have meant something else and should've asked for clarification.

Quote
For those rips that don't immediately show an AR match in the rip log, I like to use CueTools to Verify. I'd love to also be able to check against ARv2 entries at other offsets.
When you don't see results in the verify log except at another offset "Offsetted by xxx:" and tracks show "No match (V2 was not tested)" in 2.1.4 or "No match but offset" in 2.1.2a then there's a chance of ARv2 entries (see notes below). You can enter the value xxx in the Extra:Offset box and verify again to see if the ARv2 entries exist.

Note1: "No match (V2 was not tested)" and "No match but offset" can also indicate a partial match or alternate mastering which still means "No Match".
Note2: Even if all tracks show ARv1 entries at another offset there can still be ARv2 entries that weren't tested.


Thank you for the clear explanation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: geeuhnfay on 2012-06-19 20:49:41
I've been using CUEtools 2.1.4 and it's giving me these special messages when verifying some files.
I've checked the CUEtools website to see what they mean but I still don't understand what they're trying to say

"Padded some input files to a frame boundary
    File(s) truncated and do not align on a frame (sector) boundary, zeroes padded to next frame (sector) boundary "

and

"Truncated 4608 extra samples in some input files
    Extra 4608 zero samples at end of file(s) detected and removed (Detection can be disabled) "
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-06-19 20:57:05
@ Gregory
Any news/info regarding the upcoming v2.1.5 Stable version
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-19 22:31:51
I've checked the CUEtools website to see what they mean but I still don't understand what they're trying to say
Sorry for my terse definitions on the wiki and I still haven't cross-linked to the other pages I'm working on.
Quote
"Padded some input files to a frame boundary
    File(s) truncated and do not align on a frame (sector) boundary, zeroes padded to next frame (sector) boundary "
See also Audio CD Standard (http://en.wikipedia.org/wiki/Red_Book_%28audio_CD_standard%29#Technical_details) technical details. The smallest chunks of CD audio are called CD 'sectors' (also known as audio 'frames'). There are 75 per second. Each CD audio file has to start and end between two of these. This message is telling you that one or more of the the audio files are landing somewhere in the middle of a sector and that the program is adding NULL samples (or zeroes) to the file so it ends between the next two sectors. This can happen with some CUE splitting programs that do not properly decode files before splitting or when a file is damaged.
Quote
"Truncated 4608 extra samples in some input files
    Extra 4608 zero samples at end of file(s) detected and removed (Detection can be disabled) "
Some erroneous FLAC encoders add an extra 4608 NULL (zero) samples at the end of each file. The program has an option (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools#General) to detect and remove the extra samples. Leaving these samples in would result in the files not aligning on a sector boundary and changing the detected Table of Contents (TOC (http://en.wikipedia.org/wiki/Optical_disc_authoring#TOC)) so the wrong info is used for database lookups. So the message is telling you that the program detected that at least one of the files had the extra samples and removed them.


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-06-20 04:14:16
@ Gregory
Any news/info regarding the upcoming v2.1.5 Stable version

Sorry, this will probably take a few weeks more. I've just started on a new job and am somewhat overwhelmed at the moment.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-06-20 04:42:20
Some erroneous FLAC encoders add an extra 4608 NULL (zero) samples at the end of each file.

Which encoders are these?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-20 05:29:40
The [a href='index.php?showtopic=70202']Compression Offset[/a] feature in EAC was removed as of v1.0 beta 1 but it would cause this if applied to FLAC encoding.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-06-20 10:37:49
@ Gregory
Any news/info regarding the upcoming v2.1.5 Stable version

Sorry, this will probably take a few weeks more. I've just started on a new job and am somewhat overwhelmed at the moment.


Ok. Thnx for the reply/info.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-06-20 12:31:33
I've just started on a new job and am somewhat overwhelmed at the moment.

I still remember that old signature of yours
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ManicAeon on 2012-06-24 09:39:16
In main window can't set offset, cause main windows is NOT resizable.
Windows 7 x64
CUETools 2.1.4

Same text in Russian:

Невозможно выставить смещение, т.к. выставление смещения в семплах находится за границей рабочей области программы. При этом основное окно не ресайзится.
Windows 7 x64
CUETools 2.1.4

https://sourceforge.net/tracker/?func=detai...mp;atid=1118615 (https://sourceforge.net/tracker/?func=detail&aid=3537492&group_id=242216&atid=1118615)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-06-24 16:07:50
I remember similar problems caused by old version of Microsoft .NET Framework 2.0. Try to install Microsoft .NET Framework 2.0 SP2, if you don't have it installed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-06-24 16:13:11
I still remember that old signature of yours

Yep  Nice to confirm that if you have a clear goal and some patience, nothing can stop you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-25 02:30:53
I remember similar problems caused by old version of Microsoft .NET Framework 2.0. Try to install Microsoft .NET Framework 2.0 SP2, if you don't have it installed.
Win7 should have Microsoft .NET Framework 3.5.1 installed by default. However, I've duplicated what ManicAeon is seeing: Win7x64, CUETools 2.1.4, Microsoft .NET Framework 4.0.
Display font: Large (125%). {text: 'Offset' is visible, spinner is not completely visible}
Display font: Extra Large (150%) - appears fine.
Display font: Normal (100%) - appears fine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Domain on 2012-06-29 04:57:57
Sorry if this has been answered (didn't find an answer via search)...

Discovered CueTools (CueRipper mainly) while I was setting up a new machine to do some CD extraction, and quite like the software.  One of the things I noticed from the HA wiki was that FUA support is not listed, so out of curiosity I decided to take a quick peek at the source.

Now (making some assumptions since I just quickly glanced over things)... it seems that the implementation underneath (Bwg.) handling DeviceIOControl functions for SCSI MMC commands is ... well quite extensive.  As far as I can tell, the read10/read12 command already accept FUA as a boolean value for enable/disable.  From the MMC specs I belive this is all that is required to enable FUA (this of course depends on how you are making cache decisions)... though my interpretation of how this works/what you are calling underneath may be completely wrong

Any chance this would be a configuration option in the future?  Probably not high on any priority list... since I belive only a handful of drives respect this behavior (Older Plextor, etc.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dynamic on 2012-06-30 00:46:25
Loving CUEripper. I've searched and can't find this answer.

I have a couple of HDCDs, but they're packed away at the moment.

I'm wondering will CUEripper use the HDCD settings from CUEtools to detect and process HDCDs?

I'd really like to deal with the two main rarer variants among audio CDs out there at the ripping stage, namely pre-emphasis and HDCD. HDCD is the more important of the two, particularly as I often use LossyWAV and foobar2000 which can result in HDCD being detected during a silent intro then switched off once the music gets louder and the LSBs are removed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-06-30 02:01:33
Still waiting for Grigory to chime in for your first question.
In the meantime, the config is in %appdata%\CUERipper\settings.txt
Default should be:
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=0
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=1
Which are the same as CUETools Advanced Settings (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_HDCD): 0=unchecked; 1=checked.
I honestly haven't tried changing to DecodeHDCD=1 to see if it enables the next 3 settings in CUERipper.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dynamic on 2012-06-30 09:26:07
Still waiting for Grigory to chime in for your first question.
In the meantime, the config is in %appdata%\CUERipper\settings.txt
Default should be:
DetectHDCD=1
Wait750FramesForHDCD=1
[edit: deleted much of requote]


Thanks for steering me in that direction. I didn't think to look for an settings file and check. Looks encouragingly like the CUETools settings dialogue box, and hopefully theres enough code re-use that both will behave the same. Then again, might be an experimental undocumented feature.

Maybe I'll have to dig out those old Dire Straits remasters and check and report back one day.

Cheers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: n0v!ze on 2012-07-03 09:54:21
This is my first shot with CUERipper. The good thing is that the generated CUE sheet contains more data than with EAC (for example CATALOG is correctly set).  The generated log file looks overall good, here is the head:

Code: [Select]
CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 3. July 2012, 10:07

Hallows Eve / Tales of Terror

Used drive  : PLEXTOR CD-R   PX-W8432T   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 355
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

<snip>

All tracks accurately ripped

No errors occurred

End of status report


I wonder why the working (!) C2 error correction on this drive is not recognized and how to format the generated file names (don't want a period behind %tracknumber%). Also, this drive should be able to overread into Lead-In and Lead-Out.

When I open the output folder in Mp3tag then  the tag shown is APEv2 (APEv2) for all tracks  . I consider this a real error as this should be ID3v2.3 (actually that's the whole point of using True Audio instead of FLAC).

Regards
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-07-03 14:19:34
Quote
how to format the generated file names (don't want a period behind %tracknumber%).
In 2.1.4, it can be changed in Options (http://www.cuetools.net/wiki/CUERipper_Options). Prior versions go to %appdata%\CUERipper\settings.txt and adjust 'TrackFilenameFormat='.
Quote
I wonder why the working (!) C2 error correction on this drive is not recognized and ... this drive should be able to overread into Lead-In and Lead-Out.
I'll defer to the program developer but the question has been asked before.
Quote
When I open the output folder in Mp3tag then  the tag shown is APEv2 (APEv2)
Again I'll defer to the program developer but can confirm TTA and TAK are set to use APEv2 tags in CUETools/CUERipper. TagLib# (TagLib-Sharp) used for all other formats.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: n0v!ze on 2012-07-03 17:52:33
Thanks, korth.  Must have overlooked that period in the options pane.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-07-05 00:07:34
Grigory,
CUETools 2.1.4, ALAC Input and 'repair' script. Everything appears to work fine except the resulting files verify exactly the same (no change, not repaired). I ran across this by accident while running a few Encode tests. I've duplicated the results multiple times. Converting from ALAC to FLAC, then running the 'repair' script on the FLAC files, the resulting files verify accurate (repaired).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-07-05 13:31:56
Not limited to ALAC. Same problem with WV and TTA Input (multiple tries).
FLAC, APE & WAV repair OK. TAK not tested.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-07-12 01:40:28
ALAC Input and 'repair' script.

Thanks for reporting this. I made a small bugfix release to address this and 'Detailed log' problem. Didn't bump the version number, just overwrote the same download location.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-07-17 12:47:59
ALAC Input and 'repair' script.

Thanks for reporting this. I made a small bugfix release to address this and 'Detailed log' problem. Didn't bump the version number, just overwrote the same download location.


So v2.1.4 is the new stable version now?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-07-17 13:57:30
@ Gregory

Do u have any plans on adding AccurateRip cross-pressing verification?

It would be gr8 it if could be added.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-07-17 15:32:23
So v2.1.4 is the new stable version now?
If downloaded after Jul 11 2012, then v2.1.4 is labeled the current stable version.
Quote
Do u have any plans on adding AccurateRip cross-pressing verification?
You of course meant ARv2 cross-pressing verification? CUETools already has ARv1 cross-pressing verification.
I agree it should be added if possible. Perhaps even optional (can be turned on/off) or as a custom script if execution speed is still an issue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2012-07-20 11:29:43
You of course meant ARv2 cross-pressing verification? CUETools already has ARv1 cross-pressing verification.
I agree it should be added if possible. Perhaps even optional (can be turned on/off) or as a custom script if execution speed is still an issue.


Yeah, it's the ARv2 i'm talking about.

A option to turn  thecross-pressing verification On/Off would be gr8 to have available.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2012-07-20 15:17:22
IIRC Gregory mentioned that it is much harder to check cross pressing in ARv2 and questioned the need for ARv2. From Spoons latest announcements, it looks like he is ripping off Gregory's idea to do a paid service using ARv2. It even includes error correcting that Gregory pioneered.

The obvious nest step would be for spoon to kill ARv1, so everyone would have to use his paid service.

I think that we need to load as much as we can to the CueToolsDB so we can still have free functionality in the future!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2012-08-04 17:40:13
I tried running this under linux mint 13, via mono /path/to/CUETools.exe but I'm getting
Code: [Select]
Unhandled Exception: System.TypeLoadException: A type load exception has occurred.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: A type load exception has occurred.


Any idea what I might be missing?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2012-08-05 01:54:09
I'm about to re-rip my entire collection (I recently acquired an external hd large enough for me to store the lossless originals). I've been thinking I'd use CueRipper but I'm having two problems.

First, I can't seem to get the output path template to include the genre.

Second, though I see in changelogs that you have added support for MusicBrainz's new schema, I don't see any way to add most of that kind of information to the metadata.

BTW, might I suggest that you ask HA for your own subforum? Having a single thread for all support requests, announcements, development discussion, etc is extremely cumbersome.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2012-08-05 22:18:44
To be more specific about the problem with the genre: if I put %genre% in the path template it just outputs %genre%, and if I put $meta(genre) or something similar there it fails to give me a pathname at all.

I don't know whether it's relevant, but the metadata CueRipper found for the disc didn't list a genre; I put it in myself.

I ask about the new schema mostly for the ability to list other credited artists. In particular, a lot of my collection is classical music, so it's helpful to be able to list composer, performing group, and conductor.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-08-06 04:15:46
This won't help much (I'm not the developer).
To be more specific about the problem with the genre: if I put %genre% in the path template it just outputs %genre%
%genre% would be the correct syntax. [%genre%] even better to make it conditional. I can confirm that though it works in the filename template in CUETools, it does not work in CUERipper.
Quote
I don't know whether it's relevant, but the metadata CueRipper found for the disc didn't list a genre; I put it in myself.
Genre is not retrieved from MusicBrainz or Discogs.
Quote
I ask about the new schema mostly for the ability to list other credited artists. In particular, a lot of my collection is classical music, so it's helpful to be able to list composer, performing group, and conductor.
Some of the new schema can be used in the filename template only. It is currently not possible to add tags in addition to those listed in the Meta or Tracks window. You can edit the Track Artist by clicking the track # column in the track window for any track. Track Comment currently not working.
(Note: Barcode in the Meta window is written to the CUE file only as CATALOG tag.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2012-08-19 04:17:56
Unfortunate that we haven't heard back from Gregory about the %album% bug.

Another problem: CueRipper seems to reload the metadata fairly frequently. If you've made edits, they are discarded unless you've ripped the CD with those edits to the metadata. This is *extremely* frustrating when you have a CD with a lot of tracks, various track artists, etc that needs a lot of metadata attention.

I don't know what causes it. One thing that reliably seems to trigger it is reading or playing the disc with another application while I have CueRipper open with the edits. Most of the time it just seems to randomly happen while I'm typing the metadata in, but maybe there's some application, system service, etc that tries to read from the cd drive occasionally. In case it's relevant, this is on a WinXP machine with .net framework 3.5 SP1 (and of course 3.0, 2.0).

Also, if you use the button to submit changes to FreeDB they'll just send an email saying "Existing entry found with higher revision than submitted." The trouble is that CueRipper doesn't increment the revision number when you submit corrections to FreeDB. Other rippers, incl. EAC and even old CDex, automatically increase the revision number.

I'd like to reiterate my suggestion that you ask HA for a hosted subforum so not all the bug reports, discussions, etc have to be in just one thread.

BTW is it preferred to submit these to the SF bugtracker?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-08-19 12:43:04
What %album% bug? You mean %genre%? I'll look into it.

Musicbrainz: it had a lot of extra information, such as conductor/composer/etc even before new generation schema (NGS), and no, CUETools doesn't currently support most of these tags. Main change in Musicbrainz NGS (new generation schema) was replacing release events with releases, so CUETools can lets you select the correct reissue of a CD and supports Label/Catalog number/Release date.

CUERipper currently saves metadata edits only when you start ripping, and reloads it only if the system reports that a drive (not necessarily the currently selected drive) has had a disc ejected or loaded. I don't know what might cause the OS to report this erroneously (never happened to me), but i should probably make CUERipper save metadata when this happens.

I always forget to check SF bugtracker  I do read everything that's posted here, even if i'm sometimes too busy/lazy to answer.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2012-08-19 15:41:22
Yes, I mean %genre%; my bad. Thanks for looking into it.

Saving the metadata on those occasions would be a great help. If it doesn't have to be the currently selected drive which gets inserted/reloaded to cause CueRipper to reload, I wonder if the OS may be reporting erroneous events on my external hard drive which I'm saving all the music to, since it seems to spin down/spin up much more frequently than I'd wish. (Perhaps CueRipper could also restrict reloads to load/eject events on the currently selected drive?)

Thanks for the MusicBrainz clarification as well; the current behavior isn't really that problematic, I just wondered what the ngs support mentioned in the changelog amounted to.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nvrbckdwn on 2012-08-22 14:00:46
Here's my CUETools Log (Verify Mode)
Code: [Select]
[CUETools log; Date: 8/22/2012 7:57:01 PM; Version: 2.1.4]
[CTDB TOCID: hEht88BfBHFLCpTqcVzUc3NxeQM-] found.
Track | CTDB Status
  1   | (9/9) Accurately ripped
  2   | (9/9) Accurately ripped
  3   | (9/9) Accurately ripped
  4   | (9/9) Accurately ripped
  5   | (9/9) Accurately ripped
  6   | (9/9) Accurately ripped
  7   | (9/9) Accurately ripped
  8   | (9/9) Accurately ripped
  9   | (9/9) Accurately ripped
10   | (9/9) Accurately ripped
11   | (9/9) Accurately ripped
12   | (9/9) Accurately ripped
13   | (9/9) Accurately ripped
14   | (9/9) Accurately ripped
15   | (9/9) Accurately ripped
16   | (9/9) Accurately ripped
17   | (9/9) Accurately ripped
[AccurateRip ID: 002de805-0246d414-f711d611] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--  100.0 [D78D3B12] [E33CA45B]  W/O NULL
01  100.0 [5C6B629A] [2CEB2478]          
02  100.0 [2143D219] [C1819E6C]          
03   99.1 [131CA7DD] [8C89D7FA]          
04  100.0 [11C6AFAB] [CDC171C9]          
05  100.0 [63CFFACD] [9D25555F]          
06  100.0 [E4806D30] [864D8C0F]          
07  100.0 [CA68015C] [D2912A94]          
08  100.0 [1205D4C4] [FD47E5D7]          
09  100.0 [C45DCF3C] [FC743F84]          
10  100.0 [E099EADD] [20AB6016]          
11  100.0 [5EC526C6] [71A3F021]          
12  100.0 [6957FB29] [4F4E0918]          
13  100.0 [87E62411] [9108D17B]          
14  100.0 [EF7D6B45] [C1037029]          
15  100.0 [EF0A712C] [F8651FED]          
16  100.0 [CEA38418] [05E7BE21]          
17  100.0 [895E1F77] [E4BDFF83]

What does it mean? Thanks in advance for the answer. Sorry for my bad English.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-08-22 14:19:50
What does it mean?


Short answer: That your rip is OK.

It matches all of the CTDB's nine rips. CUETools finds no AccurateRip submission to compare with. The last section of the log is checksums.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-08-22 14:57:00
Here's my CUETools Log (Verify Mode). What does it mean? Thanks in advance for the answer. Sorry for my bad English.
The explanation Porcus gave is spot on but this (http://cuetools.net/wiki/CUETools_log) may help also.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2012-08-22 16:37:31
What does it mean?


Short answer: That your rip is OK.

It matches all of the CTDB's nine rips. CUETools finds no AccurateRip submission to compare with. The last section of the log is checksums.


Although the fact that the rip has 9 submissions in CTDB and none in AR is quite suspicious.

If (and I'm wildly speculating here, don't kill me  ), if the OP is veryifing a rip obtained from, cough, some other sources than his own CD, then he should not be looking at the CTDB results at all. The reason being that it is possible to submit data to CTDB directly from CUETools, after verification, without even ripping a CD. Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-08-22 16:40:06
the fact that the rip has 9 submissions in CTDB and none in AR is quite suspicious.


Isn't that the usual case for those CDs with non-standard length pregap length, that CUETools doesn't have the sufficient information to generate the AccurateRip ID?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2012-08-22 17:02:32
It should be specified in the cue sheet fed to CT, no?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2012-08-22 17:06:58
Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

Or you have a good rip, but CT says otherwise and offers to fix it with errant data?

I've seen a few titles in my collection where this could potentially happen.  Not necessarily because of "fake" submissions, but because the database could be filled with titles that were pressed from masters that had errors.

As such, I'd be reluctant to suggest that others blindly fix their rips, especially if the ripping software didn't indicate there was an issue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-08-22 17:08:35
Although the fact that the rip has 9 submissions in CTDB and none in AR is quite suspicious.

No, it's not. It's very common for new releases, because AR is only updated once per month, and CTDB is updated instantly.

If (and I'm wildly speculating here, don't kill me  ), if the OP is veryifing a rip obtained from, cough, some other sources than his own CD, then he should not be looking at the CTDB results at all.

The source of a rip doesn't have anything to do with the question and is off-topic.

Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

That is not true.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2012-08-22 17:12:05
Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

That is not true.


So there is a mechanism that somehow prevents fake submissions submitted from CUETools verification?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2012-08-22 21:30:03
Last week I'd been working on ripping my whole collection, hit the metadata reload bug several times, and quit for a while in frustration.

Today I said "I really need to get that out of the way and get all these cds out of the room; I'll just hope I can work around the problem." Had just about finished typing in the track titles (long titles - some of which require special characters- plus opus numbers etc) for one 32-track CD when it reloaded without warning and seemingly without cause. I was ticked off enough that I almost broke my keyboard.

This bug completely breaks my ability to use the software.

How difficult would this be to fix? Would it pretty much just be a matter of adding calls to data.selectedRelease.metadata.Save() in a couple choice locations?

I have no C# experience, nor do I have VS installed right now, but I do have some C, C++, and Java experience, and if it's needed to help solve the problem I could try to help debug in an effort to figure out what triggers the reload.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-08-22 21:56:16
It should be specified in the cue sheet fed to CT, no?


That's a matter of what you mean by that “should”. Users do put CUETools at work on folders without any cuesheet at all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2012-08-26 21:59:19
Gregory, are there any chances that you will:

Thank you for all your work.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wipeout on 2012-09-04 08:15:54
Is it possible to make CueRipper embed an internal cuesheet as well as the vorbis comment version in flac images? I use flactag (http://flactag.sourceforge.net/) to manage my flac images and it gets metadata from musicbrainz, using the internal cuesheet to calculate the discid in order to get to a musicbrainz release id. If not directly, if there's some scripting component I missed where I could call "metaflac --import-cuesheet-from=%filename.cue %filename.flac" after ripping a CD that would be great as well. If this is documented, I missed it and I apologize in advance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-04 13:32:19
CUERipper does embed the CUE sheet when ripping to a single-file flac image and creates a separate CUE sheet file.
The "Version" tag is not currently supported.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-05 10:55:54
The CUETools count is off by one. It shows 49 but my script counts the minimum matched is 50.

(http://sendthemtomir.com/images/2012-09-05_Belinda_Carlisle_bug.png)

Code: [Select]
for TRACK in `seq 1 10`; do cat Belinda\ Carlisle\ -\ Real.log | gawk '/^\W0*'''$TRACK'''\W.*\(.*\)\W+Accurate/ {print $3}' | tr "()/" " " | gawk '{ print $1 }' | gawk -F '+' '{ sum+=$1+$2} END {print sum}'; done

52
53
51
52
52
51
50
52
50
52
Code: [Select]
[CUETools log; Date: 9/5/2012 2:19:26 AM; Version: 2.1.4]
Offset applied: 182
[AccurateRip ID: 001228b0-0091798d-830b260a] found.
Track  [  CRC  |  V2  ] Status
 01    [71570e5b|b876ed06] (03+00/58) Accurately ripped
 02    [67668a00|8948ef9c] (03+00/59) Accurately ripped
 03    [8f3a9af7|29bfaea8] (03+00/57) Accurately ripped
 04    [f34f26e9|cf0ed7c6] (03+00/58) Accurately ripped
 05    [34edf7e7|c72e7d8c] (03+00/58) Accurately ripped
 06    [5bca7050|5941e4b2] (03+00/57) Accurately ripped
 07    [449be498|e75fbb4b] (03+00/56) Accurately ripped
 08    [ef1c16f0|ce911b56] (03+00/58) Accurately ripped
 09    [f49365df|491ce18f] (03+00/58) Accurately ripped
 10    [b1f4dc6d|739cecf0] (03+00/58) Accurately ripped
Offsetted by 23:
 01    [9011fc4a] (41/58) Accurately ripped
 02    [82366e41] (41/59) Accurately ripped
 03    [f50c3069] (40/57) Accurately ripped
 04    [61a972d4] (41/58) Accurately ripped
 05    [43843bbc] (41/58) Accurately ripped
 06    [36f10bc7] (40/57) Accurately ripped
 07    [d8de7672] (41/56) Accurately ripped
 08    [b943b741] (41/58) Accurately ripped
 09    [dc83c804] (41/58) Accurately ripped
 10    [b4f493ac] (41/58) Accurately ripped
Offsetted by 168:
 01    [8594d361] (06/58) Accurately ripped
 02    [701a0c16] (07/59) Accurately ripped
 03    [1de790a7] (06/57) Accurately ripped
 04    [3ac15171] (06/58) Accurately ripped
 05    [cbffe75f] (06/58) Accurately ripped
 06    [bdef91f8] (06/57) Accurately ripped
 07    [1b60c008] (06/56) Accurately ripped
 08    [bed95c08] (06/58) Accurately ripped
 09    [e0a6e4d7] (06/58) Accurately ripped
 10    [6ed164d5] (06/58) Accurately ripped
Offsetted by -244:
 01    [90186840] (02/58) Accurately ripped
 02    [dc2205af] (02/59) Accurately ripped
 03    [0927055f] (02/57) Accurately ripped
 04    [1dd40185] (02/58) Accurately ripped
 05    [4123284b] (02/58) Accurately ripped
 06    [041a9adc] (02/57) Accurately ripped
 07    [e81c7520] (00/56) No match (V2 was not tested)
 08    [78400e04] (02/58) Accurately ripped
 09    [bc2df083] (00/58) No match (V2 was not tested)
 10    [443aa899] (02/58) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-09-06 09:05:45
The CUETools count is off by one.


If so, then I like it that way, it prevents “verification” against my own submission. Maybe there should be a feature for “I have submitted”, or maybe (I haven't read the source) CUETools checks for log entries (/tags?) indicating that so was done?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-07 00:00:32
I have a few questions regarding s a CUETools (GUI) Verify log:

[CUETools log; Date: 9/7/2012 2:13:59 AM; Version: 2.1.4]
[CTDB TOCID: 3oyAwpWTUNxhhoGNcmgBa3GoPH4-] found.
Track | CTDB Status
  1  | (2/2) Accurately ripped
  2  | (2/2) Accurately ripped
  3  | (2/2) Accurately ripped
  4  | (2/2) Accurately ripped
  5  | (2/2) Accurately ripped
  6  | (2/2) Accurately ripped
  7  | (2/2) Accurately ripped
  8  | (2/2) Accurately ripped
  9  | (2/2) Accurately ripped
[AccurateRip ID: 0013b09d-009109a0-700d6d09] found.
Track  [  CRC  |  V2  ] Status
01    [a1fc6808|677ad65d] (4+0/4) Accurately ripped
02    [527deaee|532e0924] (4+0/4) Accurately ripped
03    [8f485bb2|30f27910] (4+0/4) Accurately ripped
04    [06692c20|6a3b2800] (4+0/4) Accurately ripped
05    [180343e7|8c2a774b] (4+0/4) Accurately ripped
06    [5c269cd6|f6fff705] (4+0/4) Accurately ripped
07    [4ef738f2|069dbe9a] (4+0/4) Accurately ripped
08    [decdd0f7|eeb83fcd] (4+0/4) Accurately ripped
09    [5e24a32a|9d5e0ae1] (0+0/4) No match

...


#1: Is the reason it's good on CTDB but not AccurateRip most likey because it's the last track and CTDB ignores a few more frames than AccurateRip does?
#2: CTDB is a whole CD checksum, correct? (This is perfect and awesome). Shouldn't the CTDB part just be "(2/2) Accurately ripped"?
#3: ArCueTools which I compile with mono for Linux does not seem to have any CTDB support. Any chance it will in the future?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-07 02:15:16
In case there are any Linux people out there, this is the command I'm currently using (2.1.4.2) to turn ArCueTools into a stand alone exe for linux:

Code: [Select]
mkbundle ArCueDotNet.exe CUETools.Processor.dll taglib-sharp.dll CUETools.Codecs.dll CUETools.Ripper.dll CUETools.CDImage.dll CUETools.Compression.dll CUETools.AccurateRip.dll CUETools.Parity.dll CUETools.CTDB.dll Freedb.dll CSScriptLibrary.v1.1.dll CUETools.Codecs.LossyWAV.dll --static --deps -o ArCueTools


You can then copy it to /usr/local/bin
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-07 02:22:08
Edit: deleted

#2. CTDB 2 now has per track verification. To see the original whole disc result, you need to enable the detailed log. See this (http://cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB). Note: There was a bug in the detailed log section in 2.1.4 if you downloaded prior to Jul 11 2012. If you're not sure you have the corrected 2.1.4, grab the latest here (http://cuetools.net/wiki/CUETools_Download).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-07 09:05:40
I have my source files on a RO (read only) drive labeled W:, and I have a RW drive labeled Y:

Input dir: W:\Iron Maiden\Iron Maiden - 2002 - Run the the Hills (CDS)\

I can set the template to: Y:\CUETmp\%filename%.cue and when I do a verify the .accurip file correctly goes there. The problem is I may have multiple cue files with the same name, ie:

Iron Maiden - 2002 - Run to the Hills (CDS)
Iron Maiden - 2002 - Run to the Hills (CDS V2)

will both have 'Iron Maiden - 2002 - Run to the Hills.flac.cue' in them. This is how I want it.

If I set the template to: Y:\CUETmp\%dirname%\%filename%.cue
I get this in the Output box: Y:\CUETmp\W:\Iron Maiden\Iron Maiden - 2002 - Run to the Hills (CDS)\Iron Maiden - Run to the Hills.flac.flac

The tooltip says it's foobar2000 format. Looking at http://wiki.hydrogenaudio.org/index.php?ti...irectoryname.25 (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Title_Formatting_Reference#.25directoryname.25)
It says:  %directoryname%  Returns the name of the parent directory only, not the complete path.

So I should have 'Y:\CUETmp\Iron Maiden - 2002 - Run to the Hills (CDS)\Iron Maiden - Run to the Hills.flac.flac', not 'Y:\CUETmp\W:\Iron Maiden\Iron Maiden - 2002 - Run to the Hills (CDS)\Iron Maiden - Run to the Hills.flac.flac'


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-07 09:29:25
I'm running today's release of 2.1.4 with detailed logs enabled. I'm seeing this a lot in the logs:

Code: [Select]
[CUETools log; Date: 9/7/2012 1:13:00 AM; Version: 2.1.4]
CD-Extra data track length 16:13:48.
[CTDB TOCID: eh.lX1OGA2fWGK0Waw.2hS7qO08-] found.
        [ CTDBID ] Status
        [a5600ba6] (71/82) , Accurately ripped
        [a5600ba6] (04/82) Has no data track, Accurately ripped
        [c702aeb1] (02/82) , Accurately ripped
        [24b2f511] (01/82) , No match
        [9c4277a2] (03/82) , Accurately ripped
        [3af65ca0] (01/82) Differs in 3 samples @45:11:59


I assume those commas should not be there?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-07 12:45:15
Here's a better example of the numbering bug. 33/34 for the entire album, but all tracks are 34/34

Code: [Select]
[CUETools log; Date: 9/7/2012 2:32:29 AM; Version: 2.1.4]
[CTDB TOCID: qUrQvKCekqMe8BhgyPUESesZhRM-] found.
        [ CTDBID ] Status
        [2fd2ac1c] (33/34) Accurately ripped
        [15d2da57] (01/34) No match
Track | CTDB Status
  1   | (34/34) Accurately ripped
  2   | (34/34) Accurately ripped
  3   | (34/34) Accurately ripped
  4   | (34/34) Accurately ripped
  5   | (34/34) Accurately ripped
  6   | (34/34) Accurately ripped
  7   | (33/34) Accurately ripped
  8   | (34/34) Accurately ripped
  9   | (34/34) Accurately ripped
10   | (34/34) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-07 13:22:28
Quote
The tooltip says it's foobar2000 format.
See also Cuetools_templates (http://cuetools.net/wiki/Cuetools_templates). Actually it's 'based on' foobar2000 format not a complete duplicaion. %directoryname% in CUETools does return the full path.
Can't you use Y:\CUETmp\%artist% - [%year% - ]%album%\%filename%.cue ?

Quote
I assume those commas should not be there?
Not if the CD-Extra data track length is the same otherwise a message would precede the comma. The original bug included discs with a CD-Extra data track. This was probably overlooked for functionality in lieu of appearance.

Quote
Here's a better example of the numbering bug. 33/34 for the entire album, but all tracks are 34/34
33/34 + 01/34 = 34/34. There are 33 matches + 1 'No match'. You'll also note that track 7 only has 33/34 matches so the maximum can only be 33/34 matches.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2012-09-07 13:29:26
Should say 33/33 since the rogue 1 clearly hasn't been validated and as such has been put in limbo.

What does AR say about this track using either EAC or dBpoweramp?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-07 14:04:56
9/10 tracks match. If you put the entire record in limbo you would also exclude the 9 matching tracks from per-track verification.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2012-09-07 15:16:14
Who said anything about putting the entire record into limbo? I was specifically talking about track 7.

Is CT handling track submissions that are not validated differently from AR?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-07 18:11:04
CTDB is still using a whole disc (modified) CRC32 as a db record identifier (CTDBID) so the non-matching Track 7 is part of the record that exists under a different CTDBID. The 34 in xx/34 are the 34 CTDBID records under that CTDB TOCID (an identifier based on the disc's TOC layout) so there are still 34 track 7's if there are 34 CTDBID records.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2012-09-07 18:15:03
Right.  I made the mistake in thinking it was an AR record that was being presented where rogue entries are suppressed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-07 22:55:32
See also Cuetools_templates (http://cuetools.net/wiki/Cuetools_templates).

Thank you. I previously looked in the wiki for that page but couldn't find it for some reason.

Quote
Can't you use Y:\CUETmp\%artist% - [%year% - ]%album%\%filename%.cue ?


That will fail all over the place:

Code: [Select]
# ls Iron\ Maiden\ -\ 2002\ -\ Run*
Iron Maiden - 2002 - Run to the Hills (CDS):
Iron Maiden - Run to the Hills.cbr   Iron Maiden - Run to the Hills.flac.cue        Iron Maiden - Run to the Hills.log
Iron Maiden - Run to the Hills.flac  Iron Maiden - Run to the Hills (Live '01).mov

Iron Maiden - 2002 - Run to the Hills (CDS V2):
Iron Maiden - Run to the Hills (Camp Chaos).mov  Iron Maiden - Run to the Hills.flac      Iron Maiden - Run to the Hills.log
Iron Maiden - Run to the Hills.cbr               Iron Maiden - Run to the Hills.flac.cue


Code: [Select]
# ls Iron\ Maiden\ -\ 1984\ -\ Power*
Iron Maiden - 1984 - Powerslave:
Iron Maiden - Powerslave.cbr  Iron Maiden - Powerslave.flac  Iron Maiden - Powerslave.flac.cue  Iron Maiden - Powerslave.log

Iron Maiden - 1984 - Powerslave (1998 Remaster):
Iron Maiden - 2 Minutes to Midnight.mov  Iron Maiden - Powerslave.cbr   Iron Maiden - Powerslave.flac.cue
Iron Maiden - Aces High.mov              Iron Maiden - Powerslave.flac  Iron Maiden - Powerslave.log



I'm either going to have to modify CUETools to get a parent directory option or attempt to set up a UnionFS. Considering I have a few thousand parent level directories (band names) I'm not sure that's going to fly. Having a %parentdir% var would be by far the easiest and cleanest.



Quote
You'll also note that track 7 only has 33/34 matches so the maximum can only be 33/34 matches.

Thank you. I saw 34/34 every time until you specifically pointed out track 7. My mistake.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-08 08:01:26
The %unique% tage is completely dead in 2.1.4. I get prompted if I want to overwrite with the following template:

Y:\CUETmp\%artist% - %album%[ - %unique%].flac.cue


Overwrite?
Y:\CUETmp\Black Sabbath - Black Sabbath.flac.accurip
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-08 12:56:49
The log file name format is specified in CUETools Advanced Settings: AccurateRip (http://cuetools.net/wiki/CUETools_Advanced_Settings:_AccurateRip#Log_file) tab under Log file; Name format:
You can change it to %filename%[ - %unique].accurip. I have it set similar.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-08 17:37:14
%filename%[ - %unique].accurip
Ooops, that should've been %filename%[ - %unique%].accurip.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Manlord on 2012-09-09 21:36:03
Has anyone tested CUERipper under Mono?

I am getting this error, but I hope it is due to the fact that I have an old version of Mono in my Debian Squeeze system:

Code: [Select]
** (CUERipper.exe:5432): WARNING **: The following assembly referenced from /home/manuel/Programas/CUETools/CUERipper.exe could not be loaded:
    Assembly:  System.Deployment    (assemblyref_index=10)
    Version:    2.0.0.0
    Public Key: b03f5f7f11d50a3a
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/manuel/Programas/CUETools/).


** (CUERipper.exe:5432): WARNING **: Could not load file or assembly 'System.Deployment, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Deployment, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
File name: 'System.Deployment, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
  at CUERipper.Program.Main () [0x00000] in <filename unknown>:0
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-11 05:39:13
Ooops, that should've been %filename%[ - %unique%].accurip.


Thank you for agreeing with me that this should have worked:

(http://www.sendthemtomir.com/images/2012-09-10_CueTools_Unique_bug.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-11 13:13:38
I did not agree with you. You didn't follow the quote-link back to my [a href='index.php?act=findpost&pid=807938']original message[/a] on the previous page. That file is not named by the template.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-12 05:26:04
That file is not named by the template.


Ahh, I understand. It's working correctly now. Thank you very much for your time in understanding this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wipeout on 2012-09-12 22:42:27
CUERipper does embed the CUE sheet when ripping to a single-file flac image and creates a separate CUE sheet file.
The "Version" tag is not currently supported.


CUERipper embeds the cuesheet as a Vorbis comment tag. However, FLAC also has a separate CUE sheet metadata tag (http://flac.sourceforge.net/format.html#metadata_block_cuesheet) specifically for single-file FLAC images. The tool I use to manage FLAC images, FLACtag (http://flactag.sourceforge.net/) needs the cuesheet information stored in that metadata tag to function effectively.

Would it be possible for CUERipper to support that metadata tag directly, or is there some way to cause CUERipper to execute a command with templated arguments so I can do it myself?

Thanks again for an awesome suite of tools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-09-20 00:53:28
When I do a Verify [default], all is good. AR 2 (Offset 676), CTDB 1:
(http://www.sendthemtomir.com/images/CUETools/2012-09-19_CUETools1.png)
(http://www.sendthemtomir.com/images/CUETools/2012-09-19_CUETools2.png)

When I do a Encode [fix offset], I get AR: disk not present in database.
(http://www.sendthemtomir.com/images/CUETools/2012-09-19_CUETools3.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-20 04:09:14
I couldn't duplicate with similar files but I don't have that particular disc. Did you try more than once to rule out a database glitch? Did you try dragging just the cue file instead of the whole folder? Were the AccurateRip ID's in both accurip files the same? (You should have both accurip files now that you're using %unique% in the log format). CTDB says AccurateRip ID: 000d3e3d-005bfdc4-700e2609 with data track length of 19:47.68. Without the data track it would have a different lookup ID ending in 6108ea08 (I don't have my script handy to calculate the first two sections).

Edit: BTW, if the disc was ripped with the proper read offset there's no need to fix the offset to match some other pressing in the database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Miguk on 2012-09-22 14:54:35
Doing encoding, in case that some files already exist, CUETools asks a question. If I answer "Yes" files will be owerwritten. If "No" - the whole operation will not start.
So, if I prefer to keep my file (for example, "folder.jpg"), it is impossible at the time.

I think, there should be a normal behavior: Yes - overwrites files, No - keeps them untouched, Cancel - cancels the started operation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-09-22 15:20:33
Corwin, I might be away for a while so let me give you one scenario where the AccurateRip ID could change resulting in "not found".
Two different AccurateRip ID's, two different results.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lvqcl on 2012-09-29 13:48:29
http://www.cuetools.net (http://www.cuetools.net) doesn't work, and CUETools cannot connect to its database
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eas on 2012-09-29 19:55:49
http://www.cuetools.net (http://www.cuetools.net) doesn't work, and CUETools cannot connect to its database


Looks like cuetools.net and db.cuetools.net are both hosted on the same server/IP, probably on Amazon EC2. It doesn't look like there are any general EC2 outages, but the server itself seems to be down, it isn't answering to pings.

I guess we can cross our fingers and wait.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-09-29 23:03:36
Thanks to everyone who tried to reach me. It turns out, that when the instance became unreachable Amazon sent me a letter: "Dear Amazon EC2 Customer, One or more of your Amazon EC2 instances in the us-east-1 region is scheduled for retirement. The following instance(s) will be shut down after 12:00 AM UTC on 2012-10-02."
Still investigating what it meant and how it happened. Anyway, relaunching the instance solved the problem. Sorry that it took so long, i was sleeping

UPD: turns out this was a hardware failure. Turns out it can still happen in the cloud  I am a bit upset with Amazon that they don't provide the option to restart the instances automatically in such cases.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dynamic on 2012-10-02 21:09:57
I like CUERipper, especially as it can rip most CDs very quickly with little wear on my optical drive in Burst mode and verify them with AccurateRip or correct small errors via CTDB and it can handle HTOA. If that fails to indicate a secure rip, or we can see in advance that the disc isn't in AR or CTDB, secure mode is also available for peace of mind.

As I've mentioned before I'd quite like a ripper that will detect and decode HDCD discs if I come across them, and ideally detect and correct those rare early PRE-emphasised CDs with non-flat EQ, which I don't think I've ever played. (I don't know whether CUETools can deal with PRE-emphasis, but hope it may be noted in CUEsheets if nothing else). Wikipedia suggests that only a few thousand HDCDs are available, so it represents a small proportion of CDs.

I don't really believe any quality claims that HDCD would be audibly better than the same content if it had been mastered to flat 16-bit PCM (or for that matter, less than 16-bit, as I'm quite happy with lossyWAV -5), so I'm mostly interested in features that might be audible, such as reversing the baked-in peak-limiting, known as peak extension (though I'm not sure I could ABX it once level-matched, but I'd rather correct for it if I can, especially as I might wish to discard the LSBs that signal HDCD is present by using lossyWAV or other lossy rather than lossless). If it turns out not to be possible I won't lose sleep over it and will just put up with undecoded HDCD, which I suspect will be pretty darned transparent and enjoyable to listen to.

I've now been able to test a HDCD pretty thoroughly to see if I can find suitable settings in the undocumented, and therefore potentially unimplemented areas of settings.txt

In short, I think I'm unable to do so...

...unless I accept the sonically transparent idea (for a committed Replay Gain user, that is) of allowing my ripper to do what an HDCD-compliant player does to redbook CDs, and bit-shift all my audio by one-bit to the right, halving its represented amplitude (easily fixed with a volume control or ReplayGain) and turning it into identical 16-bit audio in a 24-bit wrapper, where the lowest 7 bits and the highest bit will be zero padding. These 8 bits of padding will be zero unless HDCD is activated (may then use the MSB to reverse the soft-limiter and 3 bits below the normal LSB if low signal level extension is activated.

This realignment into a 24-bit wrapper has negligible bitrate penalty (a few kbps perhaps) in most lossless encoders (those that are compatible with lossyWAV - a notable exception being ALAC, which comes in over 50% higher bitrate than FLAC) and this gives a minor bitrate advantage to lossyFLAC (which no longer worries about clipping on positive peaks as it can go beyond the new peak of +0.500 within the allowed rounding error calculated by the noise-floor algorithm).

In essence this wouldn't change my workflow as someone who uses ReplayGain and usually bakes Album Gain into my lossy encodes via foobar2000 converter (or my ALAC encodes, which I can force to 16-bit, and usually do, when exporting my backing-track edits for a group's on-stage iPad).

A full requote from the original post as this was a while ago, before I run through my findings:

Still waiting for Grigory to chime in for your first question.
In the meantime, the config is in %appdata%\CUERipper\settings.txt
Default should be:
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=0
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=1
Which are the same as CUETools Advanced Settings (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_HDCD): 0=unchecked; 1=checked.
I honestly haven't tried changing to DecodeHDCD=1 to see if it enables the next 3 settings in CUERipper.

I found an HDCD to test that my cousin left when emigrating, which utilises peak extension at least on the first three tracks (Album peak 0.555992 in lossless after HDCD decoding, when it would be no more than 0.50 without peak-extension)

Although my version is labelled The Essential Alabama and appears to be a USA release through RCA, BMG & LegacyRecordings.com, it was formerly available as Alabama - For The Record and shows up under that title in CUEripper's metadata queries.

I first took a plain rip in CUERipper 2.1.2 and used CUEtools 2.1.2a to convert to 24bit lossless, which worked fine and verified OK in AccurateRip and CTDB. (I know these are now outdated, but the website was down when I started this test, so haven't updated to 2.1.4 on this PC unlike another PC I use in another location)

I then decided to modify %appdata%\CUERipper\settings.txt for various rips and copy the appropriate version of %appdata%\CUERipper\settings.txt into the folder containing that rip so I knew exactly which settings I'd set before restarting CUERipper.

I used a number of other variations in %appdata%\CUERipper\settings.txt some of which remained 16-bit and didn't decode HDCD depending on the DecodeHDCD setting, some became .20bit.20bit.flac files and some .24bit.24bit.flac files the latter depending on the DecodeHDCDTo24bit setting.

I bit-compared the entire album image at 20bit.flac versus 24bit.flac in foobar2000 Utilities/Bit Compare and no differences were found, though there were compatibility problems with 20-bit FLACs in lossyWAV - see below - so it's probably best to work with 24-bit versions, where the 4 LSBs are all zeroed:
Code: [Select]
All tracks decoded fine, no differences found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 1
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 1
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 2
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 2
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 3
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 3
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 4
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 4
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 5
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 5
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 6
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 6
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 7
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 7
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 8
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 8
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 9
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 9
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 10
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 10
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 11
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 11
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 12
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 12
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 13
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 13
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 14
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 14
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 15
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 15
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 16
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 16
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 17
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 17
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 18
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 18
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 19
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 19
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 20
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 20
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 21
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 21
No differences in decoded data found.

Comparing:
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (HDCD 20bit lossless 2)\Alabama
 - For The Record.20bit.20bit.flac" / index: 22
"C:\Users\Ryan\Music\Alabama\1998 - For The Record (unsure of settings HDCD decoded
 to 24-bit lossless)\Alabama - For The Record.24bit.24bit.flac" / index: 22
No differences in decoded data found.


CUEripper always rips to lossless or lossy as selected by the main ripping dialogues regardless of the settings line DecodeHDCDtoLossyWAV16=1 which I presume is ignored at the moment.

The following settings.txt entries (I'm just quoting the relevant lines) resulted in a successful 20bit decode and lossless rip but I was unable to rip to lossyFLAC using these settings - an error message indicated that presumably 20-bit data wasn't compatible with the lossyWAV library in CUERipper/CUETools, while I found that 24-bit was fine:
Code: [Select]
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=1
CreateM3U=0
CreateCUEFileWhenEmbedded=1
Truncate4608ExtraSamples=1
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=0

24-bit files with the 4 LSBs padded to zero, compress to the same size/bitrate as 20-bit files thanks to the unused bit feature of FLAC that's also exploited more creatively by lossyWAV. Those few encoders such as ALAC that don't work with lossyWAV inflate the bitrate greatly (about 40-50%, I believe). My FLAC bitrates were around 1046kbps for 20-bit or 24-bit decoded HDCD files.

The following settings were suitable to rip to lossyFLAC (based on 24-bit files) by selecting the lossyFLAC options in the CUERipper pull-down menus.
Code: [Select]
DetectHDCD=1
Wait750FramesForHDCD=1
DecodeHDCD=1
CreateM3U=0
CreateCUEFileWhenEmbedded=1
Truncate4608ExtraSamples=1
LossyWAVQuality=5
DecodeHDCDToLossyWAV16=0
DecodeHDCDTo24bit=1

The resulting lossyFLAC (at quality 5, standard) came out to 463kbps (versus 1046kbps for lossless decoded, and 460kbps for the un-decoded 16-bit rip - obtained using DecodeHDCD=0 and passed through lossyWAV)

I tried these settings in Image and Track modes with the same results. I was also reassured to note that the whole CD was decoded at the HDCD gain (-6.02 dB, I believe) even though peak extensions didn't appear to be used in tracks 4 to 22, thereby preserving Album Gain's inter-track differences.

The settings in the above CODE snippet will produce lossless 24-bit HDCD decodes if I select lossless and lossyWAV output based on those 24-bit decodes if I select lossyWAV without inducing error messages or incompatibilities in software that dislikes 20-bit audio.

For non HDCD discs, they throw an "Exception: HDCD not detected" and don't rip.

I tried DetectHDCD=0 and it then ripped a non HDCD disc fine, but only ripped my HDCD disc to 16-bit non-decoded (460kbps lossyWAV)

I also tried DetectHDCD=1 and Wait750FramesForHDCD=0, which worked fine for the HDCD, but decoded a non HDCD (Lyle Lovett - Step Inside This House) as if it were HDCD, resulting in 6.02 dB higher Track Gain for Track 01 - Bears, as I'd expect, with a peak of 0.5 exactly (versus 1.0 for the original), so it simply applies the -6.02 dB gain expected of an HDCD-compliant player and doesn't incorrectly peak-extend non-HDCD audio, which seems like good behaviour. The audio should be simply bit-shifted to occupy the 2nd to 17th most significant bits of a 24-bit depth (effectively the way an HDCD-compatible CD player would play back a normal CD) so there's no loss of information.

Interestingly using lossyFLAC, the peak was 0.515625, implying that as lossyWAV doesn't suffer from clipping on positive full scale samples, it can better round those samples (zeroing 10-bits out of the original 16) and zero as many bits as it calculates it should. It resulted in slightly lower bitrate for lossyFLAC -standard.

Despte the feeling that this isn't what I'd expect, this is actually a workable state of affairs for me, as I use ReplayGain and lossyWAV and FLAC and thus don't care about a lossless bit-shift and 6.02 dB attenuation of normal CDs because the original loudness is nothing sacred to me - in fact I often bake Album Gain into my lossy encodes by passing Album Gain-adjusted audio to the encoder in foobar2000 at 24 or 32 bit depth. I still get correct AccurateRip and CTDB logs from CUEripper regardless of whether I keep a 16-bit or 24-bit lossless, or some kind of lossy file, but I can't re-verify anything other than 16-bit lossless in CUETools.


So in summary, fully-automatic HDCD detection in CUEripper only works if I'm happy to bit-shift all my redbook CDs one-bit to the right (6.02 dB quieter) and store them in 24-bits. Fine with FLAC or lossy codecs. Not great if I need ALAC, but I'm not tied to any Apple products (aside from the iPad of the group I edit ALAC backing tracks for, which I do under a separate Windows User account, so if ripping CDs I'd be OK ripping to 16-bit on that account), and get a minor advantage when using lossyWAV.


If I want to stick to normal 16-bit rips for normal CDs, I'll have to accept that I'll only get HDCD decoded if I use full lossless when ripping (and use fb2k's HDCD decoder or Windows Media Player's) or if I notice the HDCD logo and either change my settings (DetectHDCD=1) for that rip alone or post-process in CUETools. Fortunately HDCD was fairly short-lived around the late 1990s (I think the only HDCDs I have are this Alabama CD and a bunch of Dire Straits Digital Remasters in storage) and they seem to sound good without decoding thanks to very modest soft limiting compared to today's Loudness War standards.

Either option is OK for me. I'll probably stick to the latter - 16-bits unless I notice the HDCD logo, but could happily change my mind with no change to my workflow.

I think dBpowerAmp might do what I hope, but when I trialled it, I didn't have an HDCD to hand to test it. I need to reinstall Windows soon, so perhaps I'll trial it again and consider buying it again. It's important that if only three tracks of 22 have HDCD features, the whole disc is still played back at -6.02 dB gain. Then again, most of my ripping is complete, aside from a few old rips I made when hard disks were much smaller and I couldn't afford to use lossless.

(edit: put linebreaks in CODEBOX to prevent excessive width of post)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-10-03 00:08:03
As I've mentioned before I'd quite like a ripper that will detect and decode HDCD discs if I come across them, and ideally detect and correct those rare early PRE-emphasised CDs with non-flat EQ, which I don't think I've ever played. (I don't know whether CUETools can deal with PRE-emphasis, but hope it may be noted in CUEsheets if nothing else).


* HDCD: Can be detected and decoded afterwards, as long as you stick to lossless. Therefore I do not convert -- I decode on-the-fly with  http://www.foobar2000.org/components/view/foo_hdcd (http://www.foobar2000.org/components/view/foo_hdcd) .

* Pre-emphasis: CUETools  does (since when I don't know) detect and write to .cue -- although, a reservation: I don't know (and didn't bother to search) whether CUETools checks both TOC and subchannel to find those which aren't flagged in both (notably, one Dark Side Of The Moon was reported released with this defect (http://www.discogs.com/Pink-Floyd-The-Dark-Side-Of-The-Moon/release/667546) -- and one Abbey Road). Unlike HDCD, you need to know this when you rip. Again, it can be decoded on-the-fly with http://www.foobar2000.org/components/view/foo_dsp_effect (http://www.foobar2000.org/components/view/foo_dsp_effect) , provided tagged. (Myself I do also keep my pre-emph'ed CDs in a different format ... making me, for the sake of 54 CDs, a WavPack user.)
There are quite a few CDs that at some stage were released in a pre-emph'ed master. A few reported here: http://www.studio-nibble.com/cd/index.php?..._(release_list) (http://www.studio-nibble.com/cd/index.php?title=Pre-emphasis_(release_list)) .
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dynamic on 2012-10-03 19:07:46
Thanks, Porcus, that's useful info.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: godrick on 2012-10-04 15:44:37
Porcus, I had no idea until yesterday that pre-emphasized discs could fail to have a TOC flag, so thanks for the info.

Does anyone know if CueRipper looks in both the TOC and subchannel for pre-emphasis detection?  If so, are special settings required or does it do it by default?  I ripped my version of DSOTM with CueRipper and pre-emphasis was not noted in the cue or log files, but I can't tell if pre-emphasis was checked but not detected or wasn't checked.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2012-10-07 07:15:53
I just tested with CUERipper 2.1.4 and my DSOTM, which has pre-emphasis flags in the subcode only, not in the TOC. I get FLAGS PRE in the cue sheet. So yes, CUERipper looks in the subcode.

Unrelated observation:

The new cover art feature of CUERipper is neat. However, I had a disc for which there were apparently multiple matches. CUERipper got the right metadata, but the wrong image was showing. I clicked on the image, and it changed to another wrong image. I clicked again, and it just kept toggling back and forth between them. On Discogs, the release doesn't have an image uploaded yet. I couldn't figure out how to get CUERipper to select "no image", though...it insisted I pick one of the available bad ones. Did I miss someting? I ended up disabling the cover art search in the options.

Also:

In CUERipper's EAC-style logs, I assume the track quality should be less than 100.0 if re-reads were required, and "Copy finished" should be the last message if the re-reads weren't able to produce a match. Yet, it seems to be "Track quality 100.0%" and "Copy OK" even when these conditions aren't met.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-09 19:53:44
When I compare EAC with CUETools then I am missing the ISRC in the cue-files.
Do I have to switch this feature on or cannot CUETools handle it (yet)?

When I use CUERipper and i get the option to choose a cover art. Is it possible to see the width and height of it (before I start ripping)?
Can I use my own scans?

CUETools has the option to submit results to CTDB.
I cannot find it for CUERipper. Does it always submit?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-10 00:19:47
CUERipper can read the ISRC codes from the CD on some drives. If you know your drive can read them, you might want to provide the make and model.

I too would like to see the cover art size displayed in CUERipper. The cover art is retrieved from MusicBrainz & Discogs. You currently can't select your own.

CUERipper always submits rip results.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-10 01:26:09
Waited too long to edit previous post.
CUERipper always submits {new} rip results. It won't submit the same result more than once.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-10 06:35:28
CUERipper can read the ISRC codes from the CD on some drives. If you know your drive can read them, you might want to provide the make and model.


I used a Plextor PX-716A to test it and it can read ISRC (by using EAC).
So I have manually no chance to switch it on and have to wait for a new release to support it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-10 14:22:18
Also my LG GSA-5163D supports ISRC.
Are there really drives who do not support that feature?

CUETools and certainly also CUERipper seem to be buggy when they write the CATALOG #:
CUETools: CATALOG 731454256223
EAC: CATALOG 0731454256223

CUETools is removing the leading 0. But it has to be a 13 digit number.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Manlord on 2012-10-10 15:00:07
CUETools and certainly also CUERipper seem to be buggy when they write the CATALOG #:
CUETools: CATALOG 731454256223
EAC: CATALOG 0731454256223

CUETools is removing the leading 0. But it has to be a 13 digit number.


Are you referring to the barcode? The format of the catalog number is label dependant. Some labels use more digits and some less.

There are barcodes with 12 and 13 digits. 12 digits are UPC codes and 13 digits are EAN codes:
http://www.gs1us.org/resources/standards/ean-upc (http://www.gs1us.org/resources/standards/ean-upc)
http://www.adams1.com/upccode.html (http://www.adams1.com/upccode.html)
http://en.wikipedia.org/wiki/Universal_Product_Code (http://en.wikipedia.org/wiki/Universal_Product_Code)
http://en.wikipedia.org/wiki/International...umber_%28EAN%29 (http://en.wikipedia.org/wiki/International_Article_Number_%28EAN%29)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-10 15:23:26
Some drives may require commands other than the current MMC standard (or additional commands required).
This can't be just switched on in the program. The program developer may or may not add features for drives that are no longer manufactured to a future release.

The leading 0 is not being added (not removed). The UPC code is 12 digits. The EAN code includes an extra digit at the beginning. The (CUE file) CATALOG tag requirement is the 13 digit EAN code. CUETools and CUERipper should be padding a zero to the beginning when retrieved codes are 12 digit UPC. I believe this has been reported but thanks for bringing it up again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-10 17:02:43
Still another question:
When release dates are retrieved then the months January till September appear as one digit (1..9). Is it possible to change it automatically to a 2-digit-date with a leading 0?

first of all for %releasedateandlabel%
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-10 22:16:05
I know that I ripped the CD accurately. But why there are 2 different CTDBIDs who confirm this?
Is it possible that 'Has no data track' is missing for the 1st one?


Quote
[CUETools log; Date: 10.10.2012 23:11:13; Version: 2.1.4]
CD-Extra data track length 07:33:60.
[CTDB TOCID: nd2_lfG342KoooYh.9YZYju3Ywo-] found.
        [ CTDBID ] Status
        [9f992239] (02/14) , Accurately ripped
        [cde4cd51] (08/14) Accurately ripped
        [a0061e98] (02/14) No match
        [c5d25191] (01/14) Has no data track, No match
        [0d1f3470] (01/14) No match
Track | CTDB Status
  1  | (10/14) Accurately ripped
  2  | (10/14) Accurately ripped
  3  | (11/14) Accurately ripped
  4  | (11/14) Accurately ripped
  5  | (11/14) Accurately ripped
  6  | (11/14) Accurately ripped
  7  | (11/14) Accurately ripped
  8  | (11/14) Accurately ripped
  9  | (11/14) Accurately ripped
10  | (11/14) Accurately ripped
11  | (14/14) Accurately ripped
12  | (14/14) Accurately ripped
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-11 04:39:04
The first one should say something like "has data track length 08:05:15," (link (http://db.cuetools.net/cd/122217)).
I'm sure Gregory will address in the next build.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-11 18:57:16
The first one should say something like "has data track length 08:05:15," (link (http://db.cuetools.net/cd/122217)).
I'm sure Gregory will address in the next build.


I still do not really understand. Does the CD exist with 2 different data track length or why a length of 07:33:60 is reported in my report?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-11 22:29:52
Nothing is actually stored about the data track in the CTDB except for the length. The length is more important when calculating the correct AccurateRip ID than for verifying within the CTDB. Entries under the same CTDB TOCID can include different pressings which may have different CD-Extra data track lengths or no CD-Extra data track at all. 

CD-Extra data track length 07:33:60.
[CTDB TOCID: nd2_lfG342KoooYh.9YZYju3Ywo-] found.
[ CTDBID ] Status
[9f992239] (02/14) Has data track length 08:05:15, Accurately ripped (added corrected text)
There are two database entries with a CD-Extra data track length 08:05:15. All 12 audio tracks match your rip.
[cde4cd51] (08/14) Accurately ripped
There are  eight database entries with a CD-Extra data track length 07:33:60. Data track length and all 12 audio tracks match your rip. 
[a0061e98] (02/14) No match
There are two database entries with a CD-Extra data track length 07:33:60. Data track length matches but one or more tracks don't match.
[c5d25191] (01/14) Has no data track, No match
There is one database entry without a data track. One or more tracks don't match.
[0d1f3470] (01/14) No match
There is one database entry with a CD-Extra data track length 07:33:60. Data track length matches but one or more tracks don't match.

CUETools log wiki page. (http://cuetools.net/wiki/CUETools_log)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2012-10-12 02:17:33
Here's another example of the CTDB numbers not adding up:
Code: [Select]
[CUETools log; Date: 10/11/2012 3:18:51 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: bjRBzVtEMk2_s9NYv_2Zbcz7LTI-] found.
        [ CTDBID ] Status
        [1fc0dcb6] (1/2) Accurately ripped
        [061116fa] (1/2) No match
Track | CTDB Status
  1   | (2/2) Accurately ripped
  2   | (2/2) Accurately ripped
  3   | (2/2) Accurately ripped
  4   | (2/2) Accurately ripped
  5   | (2/2) Accurately ripped
  6   | (2/2) Accurately ripped
[AccurateRip ID: 000e3fb7-0048d2c6-490d3306] found.
Track   [  CRC   |   V2   ] Status
01     [cc741c29|0af09c97] (02+00/21) Accurately ripped
02     [dfb97852|053ed17d] (02+00/21) Accurately ripped
....

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: PlexCSI on 2012-10-12 07:00:55
If I leave the track naming to the default in CueTools (%tracknumber%. %title%) and do a conversion, my track number tags come out correct.

However, if I modify the track naming to look more like Picard (%discnumber%-%tracknumber%. ...), all tracks on disc 1 are tagged as track 1, and all tracks on disc 2 are tagged as 2. CueTools seems to be extracting part of the filename to insert as the track tag? Is there a way to change this behavior?

I've got the code checked out and I've got functional builds, so I might look at fixing it myself. Is there any particular reason it behaves this way at present?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-12 13:34:56
Could not duplicate your result using "Audio Filenames: Track format: %discnumber%-%tracknumber%. %title%" and converting with flac input/output in windows.
All CUE file text, audio file tags and file names output as expected. Perhaps some additional information needed that you did not disclose?

BTW, I would use "[%discnumber%-]%tracknumber%. %title%" making "%discnumber%-" conditional.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: PlexCSI on 2012-10-12 17:13:49
Could not duplicate your result using "Audio Filenames: Track format: %discnumber%-%tracknumber%. %title%" and converting with flac input/output in windows.
All CUE file text, audio file tags and file names output as expected. Perhaps some additional information needed that you did not disclose?

BTW, I would use "[%discnumber%-]%tracknumber%. %title%" making "%discnumber%-" conditional.


Thanks for the quick response. I guess I may have oversimplified the problem.

I went back and looked, and here is the exact string I was using in the Filename field in the options box:

Code: [Select]
$ifgreater($max(%discnumber%,%totaldiscs%),1,%discnumber%-,)%tracknumber%. %artist% - %title%


Which does the same thing as the conditional notation you suggested (which I was unaware of previously -- thanks for that)

I had also unchecked "Write basic tags from CUE data." Enabling this seems to cause the issue to stop. Which tags does this copy? Sometimes artist, trackname, etc, is changed in the files and I would rather copy those tags from the tracks than from the CUE. Either way, this should work around the issue I have for now!

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-12 19:31:51
Quote
Which does the same thing as the conditional notation you suggested
Not exactly. The conditional [%discnumber%-] will exclude if placeholder is blank so if %discnumber% = 1, the value is still written. The function $ifgreater($max(%discnumber%,%totaldiscs%),1,%discnumber%-,) requires %discnumber% or %totaldiscs% to be greater than 1 so if both are = 1 or blank, nothing is written.
Quote
I had also unchecked "Write basic tags from CUE data."
Should have thought of that. Needs to be checked for TRACKNUMBER tag.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-14 10:25:05
I ripped a CD with EAC & CUEripper:

Quote
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 13. October 2012, 23:00

Texas / The Hush

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 3  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : No

Read offset correction                      : 30
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000


Range status and errors

Selected range

    Range quality 100.0 %
    Copy CRC 09BA44B4
    Copy OK

No errors occurred


AccurateRip summary

Track  1  cannot be verified as accurate (confidence 153)  [DE6C07CB], AccurateRip returned [9250BCF3]  (AR v2)
Track  2  cannot be verified as accurate (confidence 156)  [F2A6AF28], AccurateRip returned [1D8AF52A]  (AR v2)
Track  3  cannot be verified as accurate (confidence 159)  [D1637C4C], AccurateRip returned [64FD9888]  (AR v2)
Track  4  cannot be verified as accurate (confidence 155)  [D879924D], AccurateRip returned [476B85B9]  (AR v2)
Track  5  cannot be verified as accurate (confidence 155)  [A37502B4], AccurateRip returned [350B04D2]  (AR v2)
Track  6  cannot be verified as accurate (confidence 159)  [12AEBE11], AccurateRip returned [61FC51CA]  (AR v2)
Track  7  cannot be verified as accurate (confidence 156)  [85C9B051], AccurateRip returned [45EA6F35]  (AR v2)
Track  8  cannot be verified as accurate (confidence 157)  [1E1057B5], AccurateRip returned [6AF9FCFA]  (AR v2)
Track  9  cannot be verified as accurate (confidence 155)  [CFE693C0], AccurateRip returned [EB88AAA3]  (AR v2)
Track 10  cannot be verified as accurate (confidence 154)  [BBF9D902], AccurateRip returned [C2BF949A]  (AR v2)
Track 11  cannot be verified as accurate (confidence 153)  [02C53E65], AccurateRip returned [B53BAE1E]  (AR v2)
Track 12  cannot be verified as accurate (confidence 154)  [2022F381], AccurateRip returned [210F4576]  (AR v2)

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: .9SXrH02amvrI2s1GhjWPYvMaac-] found, Submit result: .9SXrH02amvrI2s1GhjWPYvMaac- has been confirmed
[c3e9138d] (344/348) Accurately ripped
[908c9bc8] (001/348) No match
[770a7501] (001/348) No match
[fcbe9131] (001/348) No match
[344df97a] (001/348) No match


############################################


CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 14. October 2012, 8:18

Texas / The Hush

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 30
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000


Range status and errors

Selected range
    Peak level 99.2 %
    Range quality 100.0 %
    Copy CRC 09BA44B4
    Copy OK

No errors occurred


AccurateRip summary

Track  1  cannot be verified as accurate (confidence 353)  [38B33BA2], AccurateRip returned [9250BCF3]
Track  2  cannot be verified as accurate (confidence 352)  [A2601080], AccurateRip returned [1D8AF52A]
Track  3  cannot be verified as accurate (confidence 354)  [2419DB0C], AccurateRip returned [64FD9888]
Track  4  cannot be verified as accurate (confidence 353)  [ADA913C3], AccurateRip returned [476B85B9]
Track  5  cannot be verified as accurate (confidence 352)  [91C83AF1], AccurateRip returned [350B04D2]
Track  6  cannot be verified as accurate (confidence 356)  [99A95E3D], AccurateRip returned [61FC51CA]
Track  7  cannot be verified as accurate (confidence 351)  [887BD1E2], AccurateRip returned [45EA6F35]
Track  8  cannot be verified as accurate (confidence 355)  [AC37DA17], AccurateRip returned [6AF9FCFA]
Track  9  cannot be verified as accurate (confidence 351)  [F8892BE4], AccurateRip returned [EB88AAA3]
Track 10  cannot be verified as accurate (confidence 350)  [6420CF02], AccurateRip returned [C2BF949A]
Track 11  cannot be verified as accurate (confidence 350)  [BC0874C2], AccurateRip returned [B53BAE1E]
Track 12  cannot be verified as accurate (confidence 348)  [D2FBFA4A], AccurateRip returned [210F4576]

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report


1) Why do they report 2 different adapters (1 and 3)? Which program is wrong?
2) Why do I get one time a confidence of about 150 and another of 350? EAC says ARv2 - does CUEripper not support it?
3) Why do have so many CDs a pregap of 0:33? I mean why 0:33 - I think that more than 95% of my CDs with a pregap had a pregap of 0:33. Is this only an accident?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-14 11:32:12
Too late to edit:

And a report from another CD. A CD with pregap - so I ripped with CUEripper first and then with EAC:

Quote
[CUETools log; Date: 14.10.2012 11:45:23; Version: 2.1.4]
Pregap length 00:00:33.
[CTDB TOCID: laDRh4eiGdmrlUa9aDSXWLcpY_U-] disk not present in database.


Quote
---- CUETools DB Plugin V2.1.3

[CTDB TOCID: laDRh4eiGdmrlUa9aDSXWLcpY_U-] found, Submit result: discs with pregaps not supported in this protocol version
[314aa017] (32/32) Differs in 0 samples @
You can use CUETools to repair this rip.


Where does the 32/32 come from? I thought that the disc was not present? Or is the plug-in too old ( i saw 2.1.3 only now while writing this post).

Edit:
So it was certainly the old-Plugin:

Quote
---- CUETools DB Plugin V2.1.4

[CTDB TOCID: laDRh4eiGdmrlUa9aDSXWLcpY_U-] found
Submit result: already submitted
Track | CTDB Status
  1  | (1/1) Accurately ripped
  2  | (1/1) Accurately ripped
  3  | (1/1) Accurately ripped
  4  | (1/1) Accurately ripped
  5  | (1/1) Accurately ripped
  6  | (1/1) Accurately ripped
  7  | (1/1) Accurately ripped
  8  | (1/1) Accurately ripped
  9  | (1/1) Accurately ripped
10  | (1/1) Accurately ripped
11  | (1/1) Accurately ripped


Quote
1) Why do they report 2 different adapters (1 and 3)? Which program is wrong?

Windows device manager reports channel 1 (if this is meant)

Why do I get 2 different CUE-Sheets? (to shorten it i cut out all tracks > 5)

Quote
REM DISCID 910AD50B
PERFORMER "The Mighty Lemon Drops"
TITLE "World Without End"
REM DATE 1988
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov"
FILE "The Mighty Lemon Drops - World Without End.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "Inside Out"
    INDEX 00 00:00:00
    INDEX 01 00:00:33
  TRACK 02 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "One By One"
    INDEX 01 03:23:50
  TRACK 03 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "In Everything You Do"
    INDEX 01 06:56:10
  TRACK 04 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "Hear Me Call"
    INDEX 01 12:03:00
  TRACK 05 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "No Bounds"
    INDEX 01 16:20:45
...


Quote
REM GENRE Rock
REM DATE 1988
REM DISCID 910AD50B
REM COMMENT "ExactAudioCopy v1.0b3"
CATALOG 0075992570121
PERFORMER "The Mighty Lemon Drops"
TITLE "World Without End"
FILE "The Mighty Lemon Drops - World Without End.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Inside Out"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 00:00:00
    INDEX 01 00:00:33
  TRACK 02 AUDIO
    TITLE "One By One"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 03:23:18
    INDEX 01 03:23:50
  TRACK 03 AUDIO
    TITLE "In Everything You Do"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 06:54:08
    INDEX 01 06:56:10
  TRACK 04 AUDIO
    TITLE "Hear Me Call"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 12:02:65
    INDEX 01 12:03:00
  TRACK 05 AUDIO
    TITLE "No Bounds"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 16:20:03
    INDEX 01 16:20:45
...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-14 15:39:29
Too many questions 
Quote
Why do I get one time a confidence of about 150 and another of 350?
CUERipper is combining records at all offsets. EAC doesn't do that. Examine the AccurateRip results in the accurip file from the CUERipper rip.
Quote
EAC says ARv2 - does CUEripper not support it?
CUERIpper 2.1.2-2.1.4 support ARv2.
Quote
Why do have so many CDs a pregap of 0:33?
According to the CTDB statistics (http://db.cuetools.net/stats.php), 33 ranks 2nd after 32 for discs with pregap.
Quote
Why do I get 2 different CUE-Sheets?
You mean the "Index 00" values? Index [gap] detection is another feature of the 'original' Plextor manufactured drives that might require additional read commands in CUERipper to work properly. My Plextor doesn't work correctly either. Gregory said he didn't add "Overread into Lead-In and Lead-Out" for these drives because he didn't have a drive for testing. The reason may be similar for the other features as CUERipper came about after these drives were no longer manufactured.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-14 18:34:22
Skipped your adapter question.
Quote
Why do they report 2 different adapters (1 and 3)? Which program is wrong?
CUERipper doesn't need so doesn't detect this information but because the log is an emulation of the EAC log this text is expected. CUERipper adds Adapter: 1 ID: 0 for any drive rather than omit the text in the log.
EAC interprets this information from windows and adjusts as needed for use within EAC and EAC profile .cfg files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-14 19:07:59
Quote
Why do have so many CDs a pregap of 0:33?
According to the CTDB statistics (http://db.cuetools.net/stats.php), 33 ranks 2nd after 32 for discs with pregap.


I see only 33. But my CDs were published mainly between 85 and 95. would be curious to know whether the pregap ranking is also depending on the release year.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jayess on 2012-10-19 20:26:35
Korth, a question for you. Stuff I've ripped with DbPoweramp using the HDCD plugin gives an error message when I try to verify it with CueTools.

Does ripping stuff with the HDCD plugin make the files incompatible?

I've quit ripping with it because of this and volume problems when playing mixed tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gjorgjevski on 2012-10-19 20:35:28
As far as I know, dBpoweramp’s HDCD plug-in outputs 24-bit files (with 4 bits being padded)… and you can’t really verify those with AccurateRip or the CUETools database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jayess on 2012-10-19 20:38:42
As far as I know, dBpoweramp’s HDCD plug-in outputs 24-bit files (with 4 bits being padded)… and you can’t really verify those with AccurateRip or the CUETools database.


I would agree with that and as stated that's why I no longer rip with that plugin. I went back and ripped stuff again that I had used it on, so it was a pain.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-10-19 20:58:54
Korth, a question for you. Stuff I've ripped with DbPoweramp using the HDCD plugin gives an error message when I try to verify it with CueTools.

Does ripping stuff with the HDCD plugin make the files incompatible?

I've quit ripping with it because of this and volume problems when playing mixed tracks.


This is not CUETools related; HDCD.exe changes the audio (provided it finds a HDCD, that is), and you will never get an AccurateRip match afterwards.

I did unfortunately rip a bit of my collection with the HDCD plugin. There is no reason to do so if you rip to a lossless format, and many reasons not to. The volume issue is one. I posted a few others here: http://forum.dbpoweramp.com/showthread.php...ll=1#post119732 (http://forum.dbpoweramp.com/showthread.php?25648-Questions-about-DSP-s&p=119732&viewfull=1#post119732)

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nerdyluke on 2012-10-20 18:27:29
I have a few questions regarding s a CUETools (GUI) Verify log:

[CUETools log; Date: 9/7/2012 2:13:59 AM; Version: 2.1.4]
[CTDB TOCID: 3oyAwpWTUNxhhoGNcmgBa3GoPH4-] found.
Track | CTDB Status
  1  | (2/2) Accurately ripped
  2  | (2/2) Accurately ripped
  3  | (2/2) Accurately ripped
  4  | (2/2) Accurately ripped
  5  | (2/2) Accurately ripped
  6  | (2/2) Accurately ripped
  7  | (2/2) Accurately ripped
  8  | (2/2) Accurately ripped
  9  | (2/2) Accurately ripped
[AccurateRip ID: 0013b09d-009109a0-700d6d09] found.
Track  [  CRC  |  V2  ] Status
01    [a1fc6808|677ad65d] (4+0/4) Accurately ripped
02    [527deaee|532e0924] (4+0/4) Accurately ripped
03    [8f485bb2|30f27910] (4+0/4) Accurately ripped
04    [06692c20|6a3b2800] (4+0/4) Accurately ripped
05    [180343e7|8c2a774b] (4+0/4) Accurately ripped
06    [5c269cd6|f6fff705] (4+0/4) Accurately ripped
07    [4ef738f2|069dbe9a] (4+0/4) Accurately ripped
08    [decdd0f7|eeb83fcd] (4+0/4) Accurately ripped
09    [5e24a32a|9d5e0ae1] (0+0/4) No match

...


#1: Is the reason it's good on CTDB but not AccurateRip most likey because it's the last track and CTDB ignores a few more frames than AccurateRip does?
#2: CTDB is a whole CD checksum, correct? (This is perfect and awesome). Shouldn't the CTDB part just be "(2/2) Accurately ripped"?
#3: ArCueTools which I compile with mono for Linux does not seem to have any CTDB support. Any chance it will in the future?


I have the same situation as #1 for one of my logs (last track accurate in CTDB and not accurate in AR. Can anyone please explain this ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Rollin on 2012-10-21 10:45:57

#1: Is the reason it's good on CTDB but not AccurateRip most likey because it's the last track and CTDB ignores a few more frames than AccurateRip does?
#2: CTDB is a whole CD checksum, correct? (This is perfect and awesome). Shouldn't the CTDB part just be "(2/2) Accurately ripped"?
#3: ArCueTools which I compile with mono for Linux does not seem to have any CTDB support. Any chance it will in the future?


I have the same situation as #1 for one of my logs (last track accurate in CTDB and not accurate in AR. Can anyone please explain this ?

AR ignores 5 first and 5 last frames of CD, CTDB ignores 10 first and 10 last frames of CD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nerdyluke on 2012-10-21 13:44:09
so the last track contains errors and those are located in the frames ignored by CTDB but taken into account by AR ?
also why does AR say no match instead of 'NOT ACCURATE' then ?

im confused 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-21 15:08:45
You could interpret that the differences are located in the last 6-10 sectors of the track. Not enough info to determine if from read errors, padding or a different pressing than the one in the AR database.
In the CUETools log (http://cuetools.net/wiki/CUETools_log), "No Match" = "Not Accurate"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a3aan on 2012-10-21 15:42:44
Do plans exist for supporting tagging with CTDB Accuracy values? Chaars, Adriaan.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-10-27 14:52:14
Re CD-extras:
I do lookups using the AccurateRip ID (dBpoweramp tags with those, I extract an ACCURATERIPID tag from that). However, CUETools then returns the error “Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index.”

when I check the CUEToolsDB box. And then the log ends abruptly.

If I uncheck that and only attempt verifying by AccurateRip, I get a proper log (at least this far), so it is only a minor nuissance though.


An unrelated question: what is current status on how submissions to CTDB are done? I sometimes get differences in tracks which are AR verified, making me wonder whether some upload (with a ripping error) has been downloaded, attempted verified, and ... submitted? I don't pity the downloaders, but I certainly don't trust them with repairing my rips :-o
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-27 17:58:48
An unrelated question ...
Since CTDB started per-track verification, all rip results from CUERipper and the EAC plugin are submitted but repair data is only supposed to be accepted for good rips. Per-disc verification can have several (1/x) No match results from rips with some errors by design. Those results are stored to increase confidence levels for the tracks without errors. The detailed log is Off by default so most users should only see the per-track results similar to AR.
CUETools only submits to CTDB if AR confidence is greater than 1 AND no existing entry is found in CTDB.

[EDIT]
You're probably seeing a bad repair submission from the EAC plugin. See CTDB EAC Plugin: Known_issues (http://cuetools.net/wiki/CTDB_EAC_Plugin#Known_issues). Don't trust (1/x) results for repair.
But it could also be an alternate pressing. If I ever get the guide written for the wiki, I have an example of such a disc.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-10-28 11:41:04
Since CTDB started per-track verification, all rip results from CUERipper and the EAC plugin are submitted but repair data is only supposed to be accepted for good rips.


I run the most recent CUETools.exe on my dBpoweramp rips, and it submits. At least it claims to do. So I don't know what my rips are compared to. (If I have toyed around with it for quite some time ... what prevents it form comparing to my own submissions?)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-28 13:05:19
As I already mentioned, the most recent CUETools only submits to CTDB if AR confidence is greater than 1 AND no existing entry is found for that disc in the CTDB.
If CUETools submitted after verify then AR confidence was 2 or more and no entry was found in the CTDB to compare your rip with. If you verify again and CUETools finds one CTDB entry, then yes that entry is the one you just submitted. Don't trust (1/x) results.
If dBpoweramp submitted your original rip to AR then your rip was likely one of the 2 or more AR matches found that triggered CUETools to submit.

BTW, the current CTDB will only accept a submission from CUETools if a record for that disc doesn't exist in the db so if you did use an older version of CUETools, the submission will be rejected if a record for that disc already exists.
Gregory has plans to remove the AR dependent submit feature from CUETools. The CTDB will then only accept submissions from CUERipper and the EAC plugin.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-28 23:27:07
Re CD-extras:
I do lookups using the AccurateRip ID (dBpoweramp tags with those, I extract an ACCURATERIPID tag from that). However, CUETools then returns the error “Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index.”

when I check the CUEToolsDB box. And then the log ends abruptly.

If I uncheck that and only attempt verifying by AccurateRip, I get a proper log (at least this far), so it is only a minor nuissance though.
This sounds like the 'detailed log' bug in the early version of 2.1.4. This was [a href='index.php?act=findpost&pid=801938']fixed without a version bump[/a] 11 JUL 2012. If you didn't download CUETools after 11 JUL 2012, please grab a fresh copy (http://www.cuetools.net/install/CUETools_2.1.4.rar) and try again. The alternative to unticking the CUEToolsDB box in the earlier build of 2.1.4 would be setting Detailed log (http://cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB) to false.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-10-29 06:12:55
Ah. Version bump. So that bug affects the Verify functionality and not only Repair. Thx.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-10-31 09:12:51
I use CUETools and do an encode. The 'Select the best match' window pops up.
It seems so whether I cannot remove the comment line. Editing it and keep it empty does not seem  to work.

Is there a way to embed a cuesheet into a flac file without reencoding?
Or reencode and let the original cue untouched?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-10-31 21:53:11
Quote
I use CUETools and do an encode. The 'Select the best match' window pops up.
It seems so whether I cannot remove the comment line. Editing it and keep it empty does not seem to work.
Depends on which 'best match' you select, if the source file(s) have tags and tagging settings (http://cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging). This is a legend for the icons:

(http://i.imgur.com/OomEb.jpg)
Quote
Is there a way to embed a cuesheet into a flac file without reencoding?
Not currently
Quote
Or reencode and let the original cue untouched?
Select CUE as Input. Select CUE data as 'best match'. Uncheck 'Fill up missing CUE data from tags'. Also uncheck 'Write AccurateRip tags (http://cuetools.net/wiki/CUETools_Advanced_Settings:_AccurateRip#Encode_and_verify)' on AccurateRip tab under Encode and verify.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-11-02 09:35:45
Quote
I use CUETools and do an encode. The 'Select the best match' window pops up.
It seems so whether I cannot remove the comment line. Editing it and keep it empty does not seem to work.
Depends on which 'best match' you select, if the source file(s) have tags and tagging settings (http://cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging).


I think i was not clear enough. I use mainly the data from Musicbrainz. Sometimes I edit tags - this works fine.
But when I delete a tag (remove the entry data) then it shows up at first as empty but the data was not removed.
I have to add a space ' '.
But then in the cue sheet is written REM COMMENT " ".

I delete only comment lines.

So I think that this is buggy.
Doesn't it make sense to trim all data-tags (each line if them if it is a multi-line entry)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-11-02 12:38:21
If you are trying to remove an existing comment from an embedded CUE, uncheck 'Copy basic tags (http://cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging)'.
Note: I haven't seen a Musicbrainz entry that contains a non-blank 'Comment' field. Can you provide CTDB TOCID?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-11-02 13:41:57
You could be right. Since I use mainly the data from Musicbrainz and sometimes (when Musicbrainz does not have the right data) Discogs the comment fields could appear really only in that case.
I did not realise till now that it had something to do with it

If I disable 'Copy basic tags' then nothing will ever be copied - right? Also not the label data?
And we talk about the data in the cue-sheet (incl the embedded cue-sheet) and in the flac-tags too?

What does
Quote
Copy unknown tags {checkbox}
Input audio file unknown tags are copied to output audio file tags.

exactly mean. Unknown to whom? CueTools?
Does this mean that all non-standard tags stay untouched?


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-11-02 18:46:29
Quote
If I disable 'Copy basic tags' then nothing will ever be copied - right?
You can create profiles with different settings.
Quote
Also not the label data?
If the source audio file has the LABELNO tag and the Musicbrainz entry is blank then unchecking 'Copy basic tags' will prevent that tag from being filled from the original file tag data. If the Musicbrainz entry has a value (or you edit it), that value will be written to the encoded audio file tags.
Quote
And we talk about the data in the cue-sheet (incl the embedded cue-sheet) and in the flac-tags too?
'Copy basic tags' refers to copying source audio file tags. The Embedded cue is an audio file tag. 'CUE data' is being filled from the Embedded cue but the Embedded cue is still a tag.
Quote
What does 'Copy unknown tags' exactly mean? Does this mean that all non-standard tags stay untouched?
'Unknown tags' refers to unrecognized or custom audio file tags. Checking this will copy custom tags such as MYCUSTOMTAG from the source audio file tags to the encoded audio file tags.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-11-04 15:13:42
I have now another problem:

I ripped a CD (using EAC) and the disc contains errors. After cleaning the disc I tried again. But CUETools submitted the data already to the database. Is there a way to let them delete?

What I don't understand - I always thought that the database was only accepting errorfree rips:

1st rip:

Quote
Range quality 99.5 %
    Copy CRC D3F54EEF
    Copy finished

There were errors

...

---- CUETools DB Plugin V2.1.4

[CTDB TOCID: CW4hlOgf7ZU9LaI34SGheEIRAV0-] found
Submit result: CW4hlOgf7ZU9LaI34SGheEIRAV0- has been uploaded
Track | CTDB Status
  1  | (0/1) No match
  2  | (0/1) No match
  3  | (0/1) No match


2nd rip:

Quote
Range quality 99.6 %
    Copy CRC D0822047
    Copy finished

There were errors

...

---- CUETools DB Plugin V2.1.4

[CTDB TOCID: CW4hlOgf7ZU9LaI34SGheEIRAV0-] found
Submit result: CW4hlOgf7ZU9LaI34SGheEIRAV0- has been uploaded
Track | CTDB Status
  1  | (1/2) Differs in 4764 samples @03:29:14-03:29:15,03:29:24,03:29:33-03:29:34,03:29:43,03:29:52-03:29:53,03:29:71-03:29:72,03:30:05-03:30:06,03:30:24-03:30:25,03:30:34-03:30:35,03:30:43-03:30:44,03:30:53,03:30:62-03:30:63,03:30:71-03:30:72,03:31:06-03:31:07,03:31:15-03:31:16,03:31:25-03:31:26,03:31:34-03:31:35,03:31:44-03:31:45,03:31:53-03:31:54,03:31:62-03:31:63,03:31:72-03:31:73,03:32:06-03:32:07,03:32:16-03:32:17,03:32:25-03:32:26,03:32:35-03:32:36,03:32:44-03:32:45,03:32:54,03:32:63-03:32:64,03:32:72-03:32:73,03:33:07-03:33:08,03:33:16-03:33:17,03:33:26-03:33:27,03:33:35-03:33:36,03:33:45-03:33:46,03:33:54-03:33:55,03:33:64,03:33:73-03:33:74,03:34:07-03:34:08,03:34:17-03:34:18,03:34:26-03:34:27,03:34:36-03:34:37,03:35:36-03:35:37,03:35:46-03:35:47
  2  | (2/2) Accurately ripped
  3  | (2/2) Accurately ripped
If you are sure that your rip contains errors, you can use CUETools to repair it.


3rd rip:

Quote
Range quality 99.5 %
    Test CRC DD42EF3B
    Copy CRC 32FCA2E7
    Copy finished

There were errors

...

---- CUETools DB Plugin V2.1.4

[CTDB TOCID: CW4hlOgf7ZU9LaI34SGheEIRAV0-] found
Submit result: insufficient quality
Track | CTDB Status
  1  | (1/3) Differs in 5219 samples @03:28:05,03:28:52,03:29:14-03:29:15,03:29:24,03:29:33-03:29:34,03:29:43-03:29:44,03:29:52-03:29:53,03:29:71,03:30:05-03:30:06,03:30:24-03:30:25,03:30:34-03:30:35,03:30:43-03:30:44,03:30:53,03:30:62-03:30:63,03:30:71-03:30:72,03:31:06-03:31:07,03:31:15-03:31:16,03:31:25-03:31:26,03:31:34-03:31:35,03:31:44-03:31:45,03:31:53-03:31:54,03:31:62-03:31:63,03:31:72-03:31:73,03:32:06-03:32:07,03:32:16-03:32:17,03:32:25-03:32:26,03:32:35-03:32:36,03:32:44-03:32:45,03:32:54,03:32:63-03:32:64,03:32:72-03:32:73,03:33:07-03:33:08,03:33:16-03:33:17,03:33:26-03:33:27,03:33:35-03:33:36,03:33:45-03:33:46,03:33:54-03:33:55,03:33:64,03:33:73-03:33:74,03:34:07-03:34:08,03:34:17-03:34:18,03:34:26-03:34:27,03:34:36-03:34:37, or (1/3) differs in 1501 samples @03:28:05,03:28:52,03:29:14-03:29:15,03:29:43-03:29:44,03:29:71-03:29:72,03:30:05-03:30:06,03:30:34,03:30:71-03:30:72,03:31:25,03:31:34-03:31:35,03:31:44-03:31:45,03:31:53-03:31:54,03:31:62-03:31:63,03:31:72-03:31:73,03:32:06-03:32:07,03:32:26,03:32:35,03:32:54,03:32:63-03:32:64,03:32:72-03:32:73,03:33:16-03:33:17,03:33:26-03:33:27,03:33:46,03:33:54-03:33:55,03:33:64,03:34:08,03:35:36-03:35:37,03:35:46-03:35:47
  2  | (3/3) Accurately ripped
  3  | (3/3) Accurately ripped
If you are sure that your rip contains errors, you can use CUETools to repair it.


Why the 2 first rips were accepted and the last one not?
Why was I able to upload  more than once the data? (or was it only CUEripper which prevented that?)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-11-04 15:36:19
This is a known issue (http://cuetools.net/wiki/CTDB_EAC_Plugin#Known_issues) with the EAC plugin.
All three rip results were submitted but the first two rips included repair data and the third did not. If the plugin was working as expected, none of the submitted results would include repair data. It is recommended to avoid doing a repair when the CTDB confidence is only 1/x.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-11-04 17:55:13
Quote
Why was I able to upload more than once the data?
The CTDB ID (CRC32) was different so they weren't considered duplicates. The CTDB would reject duplicate results from the same user.
Quote
Why the 2 first rips were accepted and the last one not?
The first two were ripped in 'Copy' mode which allowed the known issue (http://cuetools.net/wiki/CTDB_EAC_Plugin#Known_issues) in the plugin to submit. The  third was ripped in 'Test & Copy' mode and EAC was able to report to the plugin that the range 'Test and Copy' CRC's didn't match so the plugin did not submit based on that. Please ignore my statement above that all three were submitted. Only the first two were. It was too late to edit my original post.
Quote
I ripped a CD (using EAC) and the disc contains errors. After cleaning the disc I tried again. But CUETools submitted the data already to the database. Is there a way to let them delete?
The database will purge the confidence 1 records in time if additional matches aren't submitted and when other records for that disc exist with high confidence levels.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-11-05 06:08:56
The database will purge the confidence 1 records in time if additional matches aren't submitted and when other records for that disc exist with high confidence levels.

The disc is from 1991 - i doubt that there will be soon additional entries.
So I gave up already my hope that I will be able to repair the disc.

So it is the best for the database if we would always use only the 'test & copy'-mode?
In that case accurate stream is also not important anymore?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2012-11-17 22:50:58
I have a request, could you change the default archive of CUETools on the website from RAR to ZIP? I think it's more professional, more compatible with Windows and other systems and it doesn't need any installation of third party software.

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2012-11-18 10:06:08
I have bug report. Sometimes ISRC fields are left out from new CUEsheet if they exist in source cuesheet and copied logfile is sometimes converted from Unicode to ANSI. This is generally bad especially for EAC 1.0beta and newer logs whose are generated in Unicode and fail to be checked if in ANSI.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ClashRocker on 2012-11-19 08:03:37
I have a request, could you change the default archive of CUETools on the website from RAR to ZIP? I think it's more professional, more compatible with Windows and other systems and it doesn't need any installation of third party software.

Thanks.


+1 This....

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ClashRocker on 2012-11-19 08:10:50
Have a problem with CueRipper.

I am ripping music to "My Music" folder, and it doesn't add tags to any music.  I am using Google Music Manager to upload the music to the cloud, and everything is untagged and appears online as "unknown artist", "unknown album".

Looking at the files on disk, they too don't have any tags in them.  Tried multiple formats, all the same result.

Here is what I think it happening.

CueRipper only tags items at the end of ripping when in track mode.  Some music had already been seen by Google Music Manager and is already being uploaded. When the last track is ripped, it tries to write the tags, but one of the files is locked (by GMM), so the whole tagging operation is aborted.

Are there any plans on making an alternative strategy to combat these kinds of problems?  ( For example: Rip to a temp dir, tag when track complete not disk complete, then copy to destination?)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ClashRocker on 2012-11-21 18:32:01
Cheesy workaround time.

A batch file containing the following:

Code: [Select]
pskill -t "MusicManager.exe"
psexec "C:\Program Files\CUETools\CUERipper.exe"
psexec -d "C:\Documents and Settings\June_2\Local Settings\Application Data\Programs\Google\MusicManager\MusicManager.exe"


Need to download pstools from Microsoft:

http://technet.microsoft.com/en-us/sysinte...s/bb896683.aspx (http://technet.microsoft.com/en-us/sysinternals/bb896683.aspx)

It shuts down Google MusicManager and then launches CueTools, waits for it to exit and then runs it again.  Created a shortcut on the desktop called it CueTools, changed the icon to use the CueTools icon, and set the window state to start a minimized.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-11-21 19:18:57
Nice one  Although there is more and more software that likes to watch music folders and index/upload as soon as something is modified, so i guess CUETools should lock or hide the files until it's done with them
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-11-22 18:59:44
I have a request, could you change the default archive of CUETools on the website from RAR to ZIP? I think it's more professional, more compatible with Windows and other systems and it doesn't need any installation of third party software.

Thanks.


Zip is certainly less professional but more compatible.
RAR has its advantages over zip.
But who is really still zipping something (I mean real files not container like docx)?
RAR or 7Z - that's the only question if size matters.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-11-22 19:46:40
If users need to get themselves a copy of (the free!) 7-Zip application in order to open (the free!) CUETools packed in a way that cuts Sir Chudov's bandwidth bill, then that's not too much of a sacrifice.


Besides, 7-Zip Is Good For You.  Inter alia, because it teaches users that .zip ain't just .zip, and that you shouldn't believe Ballmerware that insinuates that your .zip is corrupted. No, .zip isn't that compatible.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2012-11-22 20:29:06
I have a request, could you change the default archive of CUETools on the website from RAR to ZIP? I think it's more professional, more compatible with Windows and other systems and it doesn't need any installation of third party software.

Thanks.


Zip is certainly less professional but more compatible.
RAR has its advantages over zip.
But who is really still zipping something (I mean real files not container like docx)?
RAR or 7Z - that's the only question if size matters.

Why less professional? I only use 7-Zip but I just want to know.
What advantages other than compress few files together? Certainly not the speed.
"EVERYONE" uses Zip because of its Windows, OSX, Linux/BSD integration.

Besides, 7-Zip Is Good For You.  Inter alia, because it teaches users that .zip ain't just .zip, and that you shouldn't believe Ballmerware that insinuates that your .zip is corrupted. No, .zip isn't that compatible.

7z = 1.46MB, RAR = 1.61MB, Zip = 2.14MB. I understand you can save some money but why use a proprietary and worse option that the open source one (7-Zip) if you really want to use "the lightest"? Also Zip of course is the best for compatibility because Windows, OSX and almost every distribution of Linux and BSD have it integrated in the system, when I have to suggest CUETools to middle age friends and they don't even know how to open the downloaded file everything stops there for me. I have to repack it in Zip, upload it on some file upload service and email them back the link.

If I don't do that and they rush on Google trying to find how to open a RAR file they may be redirected to non official websites or compatible software with malwares and toolbars. It all comes back to you and the time you have to waste apologizing because of the suggestion and the time again wasted fixing their system. Is it really about the bandwidth? I know this is extreme but if you just upload the damn Zip they'll be fine with the default Windows extractor, since Windows XP.

When you have customers you use common file extensions: PDF, Zip (not RAR, 7z), DOC/DOCX (not ODT) etc.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-11-22 21:19:13
You seem to think that «file extension» is the same as «format». It isn't. ".zip" and ".zip" are not the same. There are .zip files that Windows can natively read, and there are .zip files that Windows cannot read and will suggest that are broken, when the problem is that the file format isn't supported. That is not compatibility. It is even worse than usual incompatibility, because it doesn't give the user a single clue that the issue is incompatibility and not corruption.

".doc" and ".doc" are not the same. A ".doc" file may look totally different on two computers, even two Windows-equipped computers with Microsoft Word. And yes, even with the same versions of Microsoft Word, but with different local configuration. That issue isn't even fixed with .docx, not even with Microsoft Word 2010. Not as of November 10th, at least >:-(

".odt" and ".odt" are not the same, but at least there aren't that many variants. And anything that can read .docx , can read .odt.  ".rtf" and ".rtf" are not the same either, but less of an issue than .doc or .docx.

".pdf" and ".pdf" are not the same, and may very well look different on two computers. But in the very least Adobe gives some guidance on what to save as for archival purposes, which is a specification sufficient to grant unique appearance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2012-11-23 22:02:33
Gregory, you may consider this:

I have an album with a corrupted track. CUETools does identify the correct album though (the CTDB and AR symbols at the bottom light up with fairly high numbers), I guess the headers of the .flac show the length that should have been – but the verification aborts, and prevents verification of the remaining tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SpaceAgeHero on 2012-11-28 06:50:46
Hello,

I have a question (or feature request) regarding CUETools ability to analyze EAC logfiles.

Since CUETools is able to match CRC values from logfiles as calculated by EAC against the actual existing audio data (either as complete image or single tracks), is it possible to validate both Image CRC and Track CRCs at the same time?
This would require CUETools to analyze at least two logfiles for one disc/image (maybe based on this file naming scheme?):

Quote
"Awesome Album Title.flac"
"Awesome Album Title (Image).log"
"Awesome Album Title (Tracks).log"


The goal would be to have CUETools generate an .accurip logfile with a complete overview:

Code: [Select]
Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--  100.0 [D78D3B12] [E33CA45B]        OK
01  100.0 [5C6B629A] [2CEB2478]        OK
02  100.0 [2143D219] [C1819E6C]        OK
03   99.1 [131CA7DD] [8C89D7FA]        OK
04  100.0 [11C6AFAB] [CDC171C9]        OK
05  100.0 [63CFFACD] [9D25555F]        OK
06  100.0 [E4806D30] [864D8C0F]        OK
07  100.0 [CA68015C] [D2912A94]        OK
08  100.0 [1205D4C4] [FD47E5D7]        OK


Is this already possible somehow? If not, please consider this as a feature request. :-)

Also I'm considering to get myself a Mac. Are XLD logfiles supported already?

Thanks!!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-11-28 15:04:24
CUETools only verifies one rip at a time. Your request would require using logs from two different rips (one from an 'image' rip and one from a 'tracks' rip) and combine them into a single verification. I don't see Gregory adding this feature but you never know.
The XLD log request has been made before but not supported yet.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: landbaron on 2012-12-01 22:26:01
Hi!  Not sure if this is a feature request or bug report ... I posted elsewhere but was directed here.

I'm taking a .wav rip and cue sheet (from EAC) and using CUETools 2.1.4 to split and encode it to separate FLAC tracks, my goal being to handle HTOA well.

The CUETools "Gaps Appended + HTOA" is fantastic, exactly the functionality I was looking for, except that the FLAC produced from the HTOA, while correct, is missing any of the artist/album/track/etc FLAC tags. The other, "normal", tracks from the same rip have all tags set properly.

I realize there's the question of what track # you tag the first track with, but I don't think that's a big deal.  It'd work well enough to just call it "00", or to leave it blank, or to give the user the option to pick one of those two.

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DarkMaru on 2012-12-12 11:43:42
Hello!
Checking out new disc, I found this CUE file:
Code: [Select]
REM GENRE Progressive House
REM DATE 2005
REM DISCID E5105411
REM COMMENT "ExactAudioCopy v0.95b4"
PERFORMER "MC Вспышкин & DJ Gagarin"
TITLE "Кобасный Цех 5"
FILE "01. MC Вспышкин & DJ Gagarin - Intro.ape" WAVE
  TRACK 01 AUDIO
    TITLE "Intro"
    PERFORMER "MC Вспышкин & DJ Gagarin"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "02. MC Вспышкин & Slim line - Эффект достигнут.ape" WAVE
  TRACK 02 AUDIO
    TITLE "Эффект достигнут"
    PERFORMER "MC Вспышкин & Slim line"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "03. Prodigy - Girls (Rex The Dog remix).ape" WAVE
  TRACK 03 AUDIO
    TITLE "Girls (Rex The Dog remix)"
    PERFORMER "Prodigy"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "04. Havana Funk - Bakiri Ban (Major Boys remix).ape" WAVE
  TRACK 04 AUDIO
    TITLE "Bakiri Ban (Major Boys remix)"
    PERFORMER "Havana Funk"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "05. David Guetta feat. JD Davis - The worlds is mine (Fuck Me I'm Famous remix).ape" WAVE
  TRACK 05 AUDIO
    TITLE "The worlds is mine (Fuck Me I'm Famous remix)"
    PERFORMER "David Guetta feat. JD Davis"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "06. Boogie Pimps - Somebody to love (Steve Murano remix).ape" WAVE
  TRACK 06 AUDIO
    TITLE "Somebody to love (Steve Murano remix)"
    PERFORMER "Boogie Pimps"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "07. Stellar project feat. Brandi Emma - Get up stand up (Flipside remix).ape" WAVE
  TRACK 07 AUDIO
    TITLE "Get up stand up (Flipside remix)"
    PERFORMER "Stellar project feat. Brandi Emma"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "08. Klubbheads present Dutch Klubb Dubbs 1 - I got the love.ape" WAVE
  TRACK 08 AUDIO
    TITLE "I got the love"
    PERFORMER "Klubbheads present Dutch Klubb Dubbs 1"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "09. Pankow park - Passengers blurshake.ape" WAVE
  TRACK 09 AUDIO
    TITLE "Passengers blurshake"
    PERFORMER "Pankow park"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "10. Чугунный скороход - Afterparty.ape" WAVE
  TRACK 10 AUDIO
    TITLE "Afterparty"
    PERFORMER "Чугунный скороход"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "11. Slim line - Rape me.ape" WAVE
  TRACK 11 AUDIO
    TITLE "Rape me"
    PERFORMER "Slim line"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "12. Cosmos - Cosmos rulez.ape" WAVE
  TRACK 12 AUDIO
    TITLE "Cosmos rulez"
    PERFORMER "Cosmos"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "13. DJ Deekline pres. Cut & Run - Outta space (Booty Space mix).ape" WAVE
  TRACK 13 AUDIO
    TITLE "Outta space (booty space mix)"
    PERFORMER "DJ Deekline pres. Cut & Run"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "14. Mauro Picotto & Riccardo Ferri - New time new place (original mix).ape" WAVE
  TRACK 14 AUDIO
    TITLE "New time new place (original mix)"
    PERFORMER "Mauro Picotto & Riccardo Ferri"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "15. DJ Antoine - All we need (Pablos Bass Praise mix).ape" WAVE
  TRACK 15 AUDIO
    TITLE "All we need (Pablos Bass Praise mix)"
    PERFORMER "DJ Antoine"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "16. Eric Prydz - Call on me (radio edit).ape" WAVE
  TRACK 16 AUDIO
    TITLE "Call on me (radio edit)"
    PERFORMER "Eric Prydz"
    FLAGS DCP
    INDEX 01 00:00:00
FILE "17. DJ Nil & X-Mode - Animals.ape" WAVE
  TRACK 17 AUDIO
    TITLE "Animals"
    PERFORMER "DJ Nil & X-Mode"
    FLAGS DCP
    INDEX 01 00:00:00
If I understand correctly, this is the usual standard CUE file for VA compilation disk.
Is it possible to add a column "Artist" in the CUE file editor for the tag "PERFORMER" at the tracks?
I have two variants in my mind:
1. Always display the column "Artist". If it is empty, then do not write it in the CUE file.
2. Show column "Artist", if the tag "PERFORMER" for tracks already exists in the file.

+ Add for VA discs file mask. (For myself, I would use this "%tracknumber%. %artist% - %title%".)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-12-14 14:10:52
I get an exception: Indexes must be in chronological order with CUETools when i try to open the following CUE:

Code: [Select]
REM GENRE Christmas
REM DATE 1996
REM DISCID 09124D13
REM COMMENT "ExactAudioCopy v1.0b3"
CATALOG 0731455300222
PERFORMER "Various Artists"
TITLE "Rock Christmas - Die Neue (Volume 5)"
FILE "Various Artists - Rock Christmas - Die Neue (Volume 5).flac" WAVE
  TRACK 01 AUDIO
    TITLE "Thank God It's Christmas"
    PERFORMER "Queen"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Wonderful Christmas Time"
    PERFORMER "Paul McCartney"
    INDEX 01 04:19:55
  TRACK 03 AUDIO
    TITLE "Because It's Christmas (For All The Children)"
    PERFORMER "Barry Manilow"
    INDEX 00 04:19:55
    INDEX 01 08:06:37
  TRACK 04 AUDIO
    TITLE "Happy Xmas (War Is Over)"
    PERFORMER "John & Yoko / Plastic Ono Band, The"
    INDEX 00 04:19:55
    INDEX 01 13:35:55
  TRACK 05 AUDIO
    TITLE "Silent Night"
    PERFORMER "Sinead O'Connor"
    INDEX 00 04:19:55
    INDEX 01 17:10:20
  TRACK 06 AUDIO
    TITLE "Jingle Bells"
    PERFORMER "Yello"
    ISRC DEF079503260
    INDEX 00 04:19:55
    INDEX 01 20:52:62
  TRACK 07 AUDIO
    TITLE "The Gift Of Christmas"
    PERFORMER "Child Liners"
    INDEX 00 04:19:55
    INDEX 01 23:50:57
  TRACK 08 AUDIO
    TITLE "Last Christmas (Major Version)"
    PERFORMER "Whigfield"
    INDEX 00 04:19:55
    INDEX 01 27:55:27
  TRACK 09 AUDIO
    TITLE "The Power Of Love"
    PERFORMER "Frankie Goes To Hollywood"
    INDEX 00 04:19:55
    INDEX 01 32:09:47
  TRACK 10 AUDIO
    TITLE "It's The Most Wonderful Time Of The Year"
    PERFORMER "Amy Grant"
    INDEX 00 04:19:55
    INDEX 01 37:38:25
  TRACK 11 AUDIO
    TITLE "Children (Radio Mix)"
    PERFORMER "Hand In Hand For Children E.V."
    INDEX 00 04:19:55
    INDEX 01 40:05:62
  TRACK 12 AUDIO
    TITLE "When It's Christmas Time (Radio-Video Version)"
    PERFORMER "Worlds Apart"
    INDEX 00 04:19:55
    INDEX 01 43:39:60
  TRACK 13 AUDIO
    TITLE "Christmas Through Your Eyes"
    PERFORMER "Gloria Estefan"
    INDEX 00 04:19:55
    INDEX 01 47:45:52
  TRACK 14 AUDIO
    TITLE "Christmas Without You (Single Version)"
    PERFORMER "Bed & Breakfast"
    ISRC DEA629541240
    INDEX 00 04:19:55
    INDEX 01 52:44:70
  TRACK 15 AUDIO
    TITLE "Merry, Merry Christmas"
    PERFORMER "New Kids On The Block"
    INDEX 00 04:19:55
    INDEX 01 56:16:70
  TRACK 16 AUDIO
    TITLE "Have Yourself A Merry Little Christmas"
    PERFORMER "Vanessa Williams"
    INDEX 00 04:19:55
    INDEX 01 60:22:27
  TRACK 17 AUDIO
    TITLE "Every Year, Every Christmas"
    PERFORMER "Luther Vandross"
    INDEX 00 04:19:55
    INDEX 01 64:56:00
  TRACK 18 AUDIO
    TITLE "I Won't Be Home For Christmas (This Year)"
    PERFORMER "Be Like Water Feat. Ed. Jordan & Kreesan"
    INDEX 00 04:19:55
    INDEX 01 69:59:67
  TRACK 19 AUDIO
    TITLE "(It Must've Been Ol') Santa Claus"
    PERFORMER "Harry Connick Jr."
    INDEX 00 04:19:55
    INDEX 01 73:29:27


Other programs have no problem (like foobar).
I think CUETools has problems with the INDEX 00, INDEX 01.
With 3 of 5 Christmas CDs CUETools had this problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-12-14 14:48:20
Improper gap detection method was used in EAC. Note that all INDEX 00's are 04:19:55. Tracks 03-19 shouldn't reference the end of track 1 as a pregap starting point. Try editing the cue sheet file by deleting all the lines containing "INDEX 00 04:19:55".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2012-12-16 10:00:08
Thanks - this worked.
Only very strange that this never happened and now 3 times within of a very short time.

I have still another problem. I have an older image which is causing a 'synchonization was lost' exception.
Is in such a case the image lost or is it somehow possible to repair it?

When I check the log files of the rip:

Quote
Range status and errors

Selected range

    Timing problem 0:19:47

    Peak level 77.6 %
    Test CRC F1ABABE0
    Copy CRC F1ABABE0
    Copy finished

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 8)  [D3DF34D2]
Track  2  accurately ripped (confidence 8)  [875ED2BE]
Track  3  accurately ripped (confidence 8)  [3202B1EE]
Track  4  accurately ripped (confidence 8)  [F3819B61]
Track  5  accurately ripped (confidence 8)  [46FF31E0]
Track  6  accurately ripped (confidence 8)  [E94B29A0]
Track  7  accurately ripped (confidence 8)  [1A4B93E7]

All tracks accurately ripped

End of status report


then the timing problem was reported - but crc of test & copy were identically and also AccurateRip reported that the rip was fine.  And it was verified by Accuraterip - there was no need for me to read the log more carefully.
It was ripped with eac 0.99

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-12-16 13:18:25
Looks like a decoding problem (error in the flac file, assuming this was also a flac image). CUETools can't repair this. It might be possible to use another program to "decode through errors" but the resulting file will likely be truncated.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ecc29 on 2012-12-23 21:08:24
I get an exception: Indexes must be in chronological order with CUETools when i try to open the following CUE:

Other programs have no problem (like foobar).
I think CUETools has problems with the INDEX 00, INDEX 01.
With 3 of 5 Christmas CDs CUETools had this problem.

I just got the same problem as yours. The index00 in the cue file looks like you posted, but it's a different CD. The funny thing is, I got this index out of range error when I use cuetools' encode function. Those flac tracks was verified with confidence 3. The cue file was generated by cuetools itself during encoding. It looks like cuetools generated some poison and finally killed itself.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-12-23 22:13:56
Different error message = same problem? Please provide the cue sheet.
There was a bug introduced in the early version of 2.1.4 when 'Detailed log (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB)' was enabled and the disc had a data track. Error would read something like:
"Index was out of range. Must be non-negative and less than the size of the collection."
A new version of 2.1.4 was uploaded over the previous one 11 JUL 2012 to fix this bug without a version bump.
You could have the older one.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ecc29 on 2012-12-24 05:15:15
I checked the date of my cuetools. It's July 11 2012. Cuetools threw an exception when it was converting some flac tracks into one single ape file. The error message was "Exception: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index"

The CUE was generated by cuetools:

Code: [Select]
REM ACCURATERIPID 0019e70a-00ee2951-b30ccc0c
REM DATE 2006
PERFORMER "Benise"
TITLE "Nights of Fire!"
CATALOG 015707981125
REM DISCNUMBER 1
REM TOTALDISCS 1
FILE "Benise - Nights of Fire!.ape" WAVE
  TRACK 01 AUDIO
    TITLE "Santa Barbara"
    PERFORMER "Benise"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Monserrat"
    PERFORMER "Benise"
    INDEX 01 04:52:41
  TRACK 03 AUDIO
    TITLE "Salsa Salsa"
    PERFORMER "Benise"
    INDEX 00 04:52:58
    INDEX 01 10:07:34
  TRACK 04 AUDIO
    TITLE "Mi Amor"
    PERFORMER "Benise"
    INDEX 00 04:52:44
    INDEX 01 15:10:52
  TRACK 05 AUDIO
    TITLE "Tribal"
    PERFORMER "Benise"
    INDEX 00 04:52:59
    INDEX 01 21:14:39
  TRACK 06 AUDIO
    TITLE "Galletto's Jam"
    PERFORMER "Benise"
    INDEX 00 04:52:50
    INDEX 01 26:34:03
  TRACK 07 AUDIO
    TITLE "Long Kiss Goodbye"
    PERFORMER "Benise"
    INDEX 00 04:52:51
    INDEX 01 31:01:08
  TRACK 08 AUDIO
    TITLE "Fandango"
    PERFORMER "Benise"
    INDEX 00 04:52:46
    INDEX 01 34:39:61
  TRACK 09 AUDIO
    TITLE "Prelude/Fuego"
    PERFORMER "Benise"
    INDEX 00 04:52:51
    INDEX 01 39:54:06
  TRACK 10 AUDIO
    TITLE "Desperado"
    PERFORMER "Benise"
    INDEX 00 04:52:47
    INDEX 01 41:54:65
  TRACK 11 AUDIO
    TITLE "Shambala"
    PERFORMER "Benise"
    INDEX 00 04:52:45
    INDEX 01 46:14:58
  TRACK 12 AUDIO
    TITLE "Carnaval"
    PERFORMER "Benise"
    INDEX 00 04:52:55
    INDEX 01 50:53:24

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-12-24 17:20:34
This is an image cue sheet. If you were creating an image from tracks, this isn't the 'input' cue sheet CUETools was using that triggered the exception.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BrassDude on 2012-12-27 14:35:13
I have a weird problem with CUERipper on my new HP ProBook under Windows 8 (64 bit). When I try to rip a new CD to an image then CUERipper goes immediately into error correction mode after the first pass - and this is on a brand new CD fresh out of the box (i.e. jewel case). My drive is a HP DVD A DS8A8SH and the read offset (+6) is correctly detected and agrees with what is found on the accuraterip.com website.

So I was curious if I could rip the CD with foobar2000: see there, the CD ripped fine and was also confirmed accuraterip accurate (via CUETools). I also tested with Exact Audio Copy (EAC) and the CD ripped perfectly as well (again confirmed via CUETools).

So why is it that I can rip a CD fine with foobar2000 and EAC but not with CUERipper with the exact same hardware? What is CUERipper doing differently? Is this a problem with this specific drive? Anyone who had similar problems with HP drives?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ecc29 on 2012-12-27 23:39:28
This is an image cue sheet. If you were creating an image from tracks, this isn't the 'input' cue sheet CUETools was using that triggered the exception.

Actually, there's no such thing like 'input' cue sheet. Even without any cue sheet, you put those tracks into cuetools and generate a image after verification, cuetools will finally throw that exception.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-12-28 02:16:38
I checked the date of my cuetools. It's July 11 2012.

Try re-downloading CUETools. As Korth have suggested, this looks like a known bug which was hotfixed around that time.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ecc29 on 2012-12-29 17:04:36
Try re-downloading CUETools. As Korth have suggested, this looks like a known bug which was hotfixed around that time.

Hi Gregory, I had re-downloaded the cuetools v2.1.4 in your first post and used it again. The same problem is still there.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2012-12-30 02:54:14
Ok, i can reproduce it. It's caused by insane pre-gap information in EAC log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2012-12-30 13:38:40
Gregory,
I have CueRipper set to burst mode and its still doing significant error correction. Is this correct behavior? Is there a way to get a true burst mode?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2012-12-30 14:09:26
If the drive reports C2 errors in burst mode then up to 15 retries are done. C2 error reporting is one of the 'detected' drive features that can't be disabled.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Luke M on 2013-01-04 21:42:12
What's the easiest way to do an "in place" fix up (e.g. offset correction) of an existing rip? Cuetools doesn't seem to allow the destination to be the same as the source.

Also, how do you disable writing a .cue file? (since the rips are in files this cue is completely useless)

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-01-04 23:37:23
The output file names would need to be different. CUETools cannot overwrite the source files.

You can't disable writing the CUE file except when creating an image with embedded cue. The goal of the program is to preserve this information, not discard it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Luke M on 2013-01-05 03:26:59
You can't disable writing the CUE file except when creating an image with embedded cue. The goal of the program is to preserve this information, not discard it.


That would make sense if I were creating an image. But I'm not.

The information is already stored twice, in the tags and the filename. Why do I need THREE copies of the same information?

Example cue file generated by cuetools:

REM COMMENT "CUETools generated dummy CUE sheet"
PERFORMER "Samuel Barber"
TITLE "Schenck Fadograph"
FILE "Samuel Barber - Schenck Fadograph - 01 - Fadograph of a Yestern Scene.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Fadograph of a Yestern Scene"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 02 - Medea (Suite) - Parados.flac" WAVE
  TRACK 02 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Medea (Suite) - Parados"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 03 - Medea (Suite) - Choros.flac" WAVE
  TRACK 03 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Medea (Suite) - Choros"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 04 - Medea (Suite) - The Young Princess.flac" WAVE
  TRACK 04 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Medea (Suite) - The Young Princess"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 05 - Medea (Suite) - Choros.flac" WAVE
  TRACK 05 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Medea (Suite) - Choros"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 06 - Medea (Suite) - Medea.flac" WAVE
  TRACK 06 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Medea (Suite) - Medea"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 07 - Medea (Suite) - Kantikos Agonias.flac" WAVE
  TRACK 07 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Medea (Suite) - Kantikos Agonias"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 08 - Medea (Suite) - Exodos.flac" WAVE
  TRACK 08 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Medea (Suite) - Exodos"
    INDEX 01 00:00:00
FILE "Samuel Barber - Schenck Fadograph - 09 - Third Essay.flac" WAVE
  TRACK 09 AUDIO
    PERFORMER "Samuel Barber"
    TITLE "Third Essay"
    INDEX 01 00:00:00
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-01-05 04:13:25
Please put CUEs, LOGs or other examples in a codebox.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-05 04:35:39
What's the easiest way to do an "in place" fix up (e.g. offset correction) of an existing rip? Cuetools doesn't seem to allow the destination to be the same as the source.

Also, how do you disable writing a .cue file? (since the rips are in files this cue is completely useless)

Thanks.


Although offset correction was one of the first features i implemented when i started to work on cuetools, i have long since decided that it's quite useless. Offset correction doesn't add anything to the quality of your files, and even subtracts a few samples. You don't need to apply offset to be able to verify your rip, and it doesn't affect how it sounds. Each time when i release a new CUETools version, i am strongly tempted to remove offset correction feature altogether.

In-place conversion is one of frequently requested features, it's on my list.

And unfortunately you can't disable writing a .cue file, but it's also on my list mainly because it's useless when converting to lossy formats.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-01-05 05:04:45
You don't need to apply offset to be able to verify your rip
Without ARv2 cross-pressing verification, you still need it in the 'Extra' section on occasion to verify when no entries in CTDB.
Quote
And unfortunately you can't disable writing a .cue file, but it's also on my list mainly because it's useless when converting to lossy formats.
Thanks for the clarification. My [a href='index.php?act=findpost&pid=819445']comment[/a] was regarding preserving disc structure for lossless rips.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2013-01-08 19:54:06
And unfortunately you can't disable writing a .cue file, but it's also on my list mainly because it's useless when converting to lossy formats.


Are ISRC data stored in the image? How can I retrieve these again?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-01-09 00:15:40
ISRC data is usually found in the Q sub-channel of the CD. When ripping to a WAV CDImage, the retrieved sub-channel data is saved in the CUE sheet as CATALOG, FLAGS, ISRC... If the WAV is compressed, the data can also be stored in the metadata.
[a href='index.php?showtopic=98359']Interesting thread on ISRC.[/a]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2013-01-13 16:39:54
I wish that the next version of CUEripper would have a button zo open/close the tray of the drive.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ttolnai on 2013-01-16 04:37:46
I can't use CueTools under Windows 8.
How can I use it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-16 04:39:38
What do you mean you can't use it? Works for me...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ttolnai on 2013-01-16 04:46:30
The program don't run
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-16 04:48:24
Any error messages?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ttolnai on 2013-01-16 04:51:01
No message...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ttolnai on 2013-01-16 04:53:42
Succes 
Under explorer.
Thaks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2013-01-19 12:45:38
I get now suddenly again and again an exception with CUERipper:

Exception: Error reading CD: IoctlFailed

This happens directly after gap detection - progressbar is at 1% and the status says Ripping @03,42x...

When I switch the drive off and on (externel USB 3) then it works again.
What could be the reason for it?

Edit:
After the error CUERipper shows

Open failed: Datenfehler (CRC-Prüfung) (Ausnahme von HRESULT: 0x80070017)

I can only access the disc again when I close CUERipper. But re-ripping again is causing the same error. I have to switch off the drive
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2013-01-19 19:00:20
How can I edit track data with CUERipper?
I have a compilation disc which was only known by freedb. I can edit the titles. But I do not see where I can switch to compilation so the performer column will be visible (and editable)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-19 19:00:58
What's the model of your drive? What changed before it started to happen? New drive or new driver? Does it happen on every CD?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-19 19:02:42
In the tracklist, click on any other column but Title
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2013-01-19 19:08:59
What's the model of your drive? What changed before it started to happen? New drive or new driver? Does it happen on every CD?


Asus BW-12D1S-U - it is a rebadged Pioneer BDR-207 (less than 6 months old).
I tested the last hours still a little bit.
It does not happen  always. I had till now 3 problematic discs (all were maxi CDs). 2 of them I could reread after switching the drive off and on.
But the third one is creating always the error message.

All 3 problematic discs work fine in a Plextor PX-B310U - so it has to be drive specific.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2013-01-19 19:12:00
In the tracklist, click on any other column but Title

I clicked on title and the last column (the empty one after length) but to click on the time - I would have never thought of this.
But it works now 

Still another problem. CUEripper 'found' a 1x1 pixel album art jpg for one of my CDs. In the preview I couldn't see it - but shouldn't be there minimum sizes of the artwork?

And staying at this topic here are still some ideas:
- please show the size of the chosen graphics - like 600x600
- Can I remove the album art within of CUEripper when it is not the right one? And can I add my own one?
- a 1:1 preview of the available album arts would be nice & useful
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-01-19 22:59:24
Quote
I clicked on title and the last column (the empty one after length) but to click on the time - I would have never thought of this.
It was on the CUETools wiki (http://www.cuetools.net/wiki/CUERipper_Settings#.284.29_Tracks_window), though my descriptions are rather brief.
Quote
Can I remove the album art within of CUEripper when it is not the right one?
If more than one image is available (like from a different metadata source) you can mouse click on the preview image to switch to the next image. (wiki link (http://www.cuetools.net/wiki/CUERipper_Settings#.2819.29_Album_Art_preview))
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tubebend on 2013-01-20 19:54:51
Hi,

my first post here and I feel quite excited about all the friendly provided knowledge. Hoping for a warm welcome!

I'm using EAC with CTDB plugin 2.1.3. Works well, I feel that my rips are now as good as needed. I want to place a small feature request for the CTDB plugin: In the EAC's database search pop-up I normally use the Musicbrainz entry to tag my release. Needed information to choose the right release is e. g. the barcode or the label. It is perhaps possible to write one of the unique release data to the EAC comment field? Then it would be possible to re-tag the tracks afterwards via Musicbrainz Picard much more easily.

Thanks in advance

Tubebend
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-20 21:40:59
Probably a good idea. Although the best solution would probably be to convince Andre to add support for such additional metadata fields in EAC, for example to let the plugin manipulate Vorbis comment fields directly - then there would be no need to use Picard
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tubebend on 2013-01-20 22:10:45
Thanks for the reply!

You're right - it would probably be the best solution to ask Andre to implement this (and other) features in EAC. On the other hand I do not think that EAC's goal is to offer best quality meta data... Your CTDB plugin already comes up with the needed information serveed on a silver platter - but unfortunately the information is not processable. Up to now I'm typewriting the barcode into EAC's comment field to refine my tags afterwards. It works but is far away from convenience.

So perhaps any chance to get this feature implemented in CTDB plugin?!?

Cheers, Tubebend
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tubebend on 2013-01-20 23:02:50
Another question:

At which state of the EAC ripping process does the plugin append it's own log to the EAC log? I move the EAC log by a cmd batch to the desired directory after the last track has been encoded to FLAC. The batch waits for the EAC log to be written and then moves it. I feel that sometimes the log is moved too fast and that the plugin has no chance to write it's own report then. But this behaviour is not reproducable - I already implemented some waiting loops but sometimes it works - sometimes not.

Cheers, Tubebend
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-20 23:21:21
Plugin only returns the data to EAC, EAC puts it into its log file. I think EAC also puts its signature after it puts plugin messages. So if you have EAC signature but no plugin log, it means that plugin returned no messages.

CTDB plugin returns no messages if you are copying only some tracks and not an entire disc. Old versions of plugin also ignored discs with pregap in file-per-track mode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-01-20 23:31:24
I'm using EAC with CTDB plugin 2.1.3
PMJI, I just wanted to point out that version 2.1.4 of the plugin is available here (http://www.cuetools.net/install/CUETools.CTDB.EACPlugin.2.1.4.rar). This version doesn't address any of the concerns you mentioned but is more compatible with the per-track verification of CTDB 2.0.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tubebend on 2013-01-21 11:57:03
I will update to 2.1.4 then.

I noticed the missing CTDB-log when ripping complete releases. Just to clearify myself: If the disc is not in the CueTools database no log will be transferred to EAC? I'm quite sure that CTDB logs were also missing for common releases but I will check this again when at home this evening (UTC+1). There is no extra EAC signature entry after a CTDB log. The plugin compares the rip with the database on the web after the last track, right? Perhaps I closed the EAC log pop-up too fast? In the EAC UI-report never the CTDB log is shown. Only in the log files like this one:

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011
EAC extraction logfile from 28. December 2012, 13:16
Héroes del Silencio / Senderos de traición
...
snipped
...
Track 12

     Filename D:\Users\Public\Music\_EAC\1-12 El cuadro II.wav

     Peak level 91.7 %
     Extraction speed 17.1 X
     Track quality 99.9 %
     Copy CRC 3E33F8C7
     Accurately ripped (confidence 41)  [0A4A21BD]  (AR v2)
     Copy OK


All tracks accurately ripped

No errors occurred

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: wmQoNFieqbt48ZkVJRPHRHXU06Y-] found, Submit result: wmQoNFieqbt48ZkVJRPHRHXU06Y- has been confirmed
[b938fa33] (298/304) Accurately ripped
[bd8aa32c] (001/304) No match
[87754ec9] (001/304) No match
[8cb3c7b5] (001/304) No match
[044d6f8e] (001/304) No match
[748b3eab] (001/304) No match
[9e05eafc] (001/304) No match


Will keep you informed about further investigations...

Cheers, Tubebend
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-01-21 13:35:36
Rip is processed after the last track.
Plugin message is appended to the '.log' file, not EAC's 'Status and Error Messages' window.
Plugin message will be added to the log file telling you 'submission status' if disc is not found in CTDB.
More info here (http://www.cuetools.net/wiki/CTDB_EAC_Plugin).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: unfinished.hide on 2013-01-22 00:02:19
Hi Gregory, long time user of CUETools here, so let me thank you for this great little piece of software.

I just have a small feature request which I don't know if it's been asked already: Would it be possible to add in the CUETools log information about the flags found on cuesheets, if any? I know they're not very usual, but it would be especially helpful when a preemphasis flag is detected to have that info available at a quick glance there along with the other reports.

Regards.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-01-23 03:50:54
Ok, not sure why this is. Ripped a CD with dBpoweramp, and I was unable to rip one of the tracks, so I repaired with CTDB and CueTools, however, even though all of the other tracks are confirmed by dBpoweramp/Accuraterip, CueTools says the disc is not in AccurateRip, and the CueTools log does not show the normal CTDB results...


dBpoweramp Log

Code: [Select]
dBpoweramp Release 14.4 BETA Digital Audio Extraction Log from Tuesday, January 22, 2013 19:59

Drive & Settings
----------------

Ripping with drive 'G:  [PLEXTOR  - CD-R  PX-W4824A]',  Drive offset: 98,  Overread Lead-in/out: No
AccurateRip: Active,  Using C2: Yes,  Cache: 1171 KB,  FUA Cache Invalidate: Yes
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Ultra::  Vary Drive Speed: No,  Min Passes: 3,  Max Passes: 6,  Finish After Clean Passes: 2
Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 34

Encoder: FLAC -compression-level-6 -verify
DSP Effects / Actions: -dspeffect1="ReplayGain=-albummode={qt}0{qt}"



Track Technical Details
-----------------------

Track 1: HDCD
Track 2: HDCD
Track 3: HDCD
Track 4: HDCD
Track 5: HDCD
Track 6: HDCD
Track 7: HDCD
Track 8: HDCD
Track 9: HDCD
Track 10: HDCD
Track 11: HDCD
Track 12: HDCD
Track 13: HDCD
Track 14: HDCD
Track 15: HDCD
Track 16: HDCD
Track 17: HDCD
Track 18: HDCD
Extraction Log
--------------

Track 1:  Ripped LBA 33 to 23935 (5:18) in 0:32. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\01 - Box of Rain.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: E591EA61 AccurateRip CRC: C3B69A41 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-1]
  AccurateRip Verified Confidence 12 [CRCv2 c3b69a41]
  AccurateRip Verified Confidence 108 [CRCv1 bd8d41cf]

Track 2:  Ripped LBA 23935 to 39285 (3:24) in 0:20. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\02 - Friend of the Devil.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: 830E6AE6 AccurateRip CRC: 548A053D (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-2]
  AccurateRip Verified Confidence 12 [CRCv2 548a053d]
  AccurateRip Verified Confidence 109 [CRCv1 787749f6]

Track 3:  Ripped LBA 39285 to 54235 (3:19) in 0:14. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\03 - Sugar Magnolia.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: F061E797 AccurateRip CRC: 3B451526 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-3]
  AccurateRip Verified Confidence 12 [CRCv2 3b451526]
  AccurateRip Verified Confidence 108 [CRCv1 2013cdd3]

Track 4:  Ripped LBA 54235 to 65168 (2:25) in 0:10. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\04 - Operator.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: D39BA09A AccurateRip CRC: 5B514972 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-4]
  AccurateRip Verified Confidence 12 [CRCv2 5b514972]
  AccurateRip Verified Confidence 108 [CRCv1 9e27ccbf]

Track 5:  Ripped LBA 65168 to 93205 (6:13) in 0:24. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\05 - Candyman.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: 18218DA2 AccurateRip CRC: EF3D0B59 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-5]
  AccurateRip Verified Confidence 12 [CRCv2 ef3d0b59]
  AccurateRip Verified Confidence 107 [CRCv1 a6b74d22]

Track 6:  Ripped LBA 93205 to 111950 (4:09) in 0:15. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\06 - Ripple.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: DAA5A215 AccurateRip CRC: 2AF0E967 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-6]
  AccurateRip Verified Confidence 12 [CRCv2 2af0e967]
  AccurateRip Verified Confidence 108 [CRCv1 2aa2d1e0]

Track 7:  Ripped LBA 111950 to 130625 (4:09) in 0:14. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\07 - Brokedown Palace.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: 7FBA6CA2 AccurateRip CRC: CC771906 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-7]
  AccurateRip Verified Confidence 12 [CRCv2 cc771906]
  AccurateRip Verified Confidence 106 [CRCv1 5e5c2878]

Track 8:  Ripped LBA 130625 to 144803 (3:09) in 0:10. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\08 - Till the Morning Comes.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: A0CEF64D AccurateRip CRC: 13BBA324 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-8]
  AccurateRip Verified Confidence 12 [CRCv2 13bba324]
  AccurateRip Verified Confidence 107 [CRCv1 7f143d9c]

Track 9:  Ripped LBA 144803 to 168373 (5:14) in 0:17. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\09 - Attics of My Life.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: 497C07F8 AccurateRip CRC: 808FE9A0 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-9]
  AccurateRip Verified Confidence 12 [CRCv2 808fe9a0]
  AccurateRip Verified Confidence 107 [CRCv1 b9ff44dd]

Track 10:  Ripped LBA 168373 to 192213 (5:17) in 0:16. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\10 - Truckin'.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: CF4BAC02 AccurateRip CRC: 712C39DD (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-10]
  AccurateRip Verified Confidence 12 [CRCv2 712c39dd]
  AccurateRip Verified Confidence 107 [CRCv1 d4b34b4f]

Track 11:  Ripped LBA 192213 to 207005 (3:17) in 0:49. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\11 - Truckin' (Single Version).flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: 06C3E623 AccurateRip CRC: E9A485A2 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-11]
  AccurateRip Verified Confidence 12 [CRCv2 e9a485a2]
  AccurateRip Verified Confidence 104 [CRCv1 90befb04]

Track 12:  Ripped LBA 207005 to 226648 (4:21) in 0:13. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\12 - Friend of the Devil (live).flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: DE125B96 AccurateRip CRC: AAB195F5 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-12]
  AccurateRip Verified Confidence 12 [CRCv2 aab195f5]
  AccurateRip Verified Confidence 102 [CRCv1 88b06c95]

Track 13:  Ripped LBA 226648 to 250508 (5:18) in 0:15. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\13 - Candyman (live).flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: 68298FD0 AccurateRip CRC: CF3107A1 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-13]
  AccurateRip Verified Confidence 12 [CRCv2 cf3107a1]
  AccurateRip Verified Confidence 101 [CRCv1 62b1b964]

Track 14:  Ripped LBA 250508 to 265555 (3:20) in 0:09. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\14 - Till the Morning Comes (live).flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: BA017F2B AccurateRip CRC: D0F044D0 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-14]
  AccurateRip Verified Confidence 12 [CRCv2 d0f044d0]
  AccurateRip Verified Confidence 101 [CRCv1 b741e97f]

Track 15:  Ripped LBA 265555 to 294895 (6:31) in 0:18. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\15 - Attics of My Life (live).flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: 7F3811B2 AccurateRip CRC: E172D235 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-15]
  AccurateRip Verified Confidence 12 [CRCv2 e172d235]
  AccurateRip Verified Confidence 103 [CRCv1 adcdc412]

Track 16:  Ripped LBA 294895 to 340655 (10:10) in 2:39. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\16 - Truckin' (live).flac
  Insecure  [Pass 1, Ultra 1 to 3, Re-Rip 144 Frames]
  CRC32: 5D5F1A77 AccurateRip CRC: FFBC835D (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-16]
  ** Reached Maximum 3 Unrecoverable Frames For This Track
Insecure Audio from 00:02:41.813 to 00:02:41.826
Insecure Audio from 00:02:42.960 to 00:02:42.973
Insecure Audio from 00:02:43.533 to 00:02:43.826
Insecure Audio from 00:05:54.333 to 00:05:54.346
Insecure Audio from 00:05:55.493 to 00:05:55.506
Insecure Audio from 00:06:01.586 to 00:06:03.333

Track 17:  Ripped LBA 340655 to 354288 (3:01) in 0:08. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\17 - [Untitled Hidden Track].flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: A277CC7E AccurateRip CRC: 2837EA7B (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-17]
  AccurateRip Verified Confidence 12 [CRCv2 2837ea7b]
  AccurateRip Verified Confidence 99 [CRCv1 75f8383d]

Track 18:  Ripped LBA 354288 to 359575 (1:10) in 0:03. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\18 - American Beauty Radio Spot.flac
  AccurateRip: Accurate (confidence 12) [Pass 1]
  CRC32: FBABF45B AccurateRip CRC: 6408B07F (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-18]
  AccurateRip Verified Confidence 12 [CRCv2 6408b07f]
  AccurateRip Verified Confidence 96 [CRCv1 89c0b1c9]

--------------

18 Tracks Ripped: 17 Accurate, 1 Inaccurate


====================

dBpoweramp Release 14.4 BETA Digital Audio Extraction Log from Tuesday, January 22, 2013 20:08

Drive & Settings
----------------

Ripping with drive 'D:  [TSSTcorp - CDDVDW SH-S203B ]',  Drive offset: 6,  Overread Lead-in/out: No
AccurateRip: Active,  Using C2: Yes,  Cache: 2 KB,  FUA Cache Invalidate: No
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Ultra::  Vary Drive Speed: No,  Min Passes: 3,  Max Passes: 6,  Finish After Clean Passes: 2
Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 34

Encoder: FLAC -compression-level-6 -verify
DSP Effects / Actions: -dspeffect1="ReplayGain=-albummode={qt}0{qt}"



Track Technical Details
-----------------------

Track 16: HDCD
Extraction Log
--------------

Track 16:  Ripped LBA 294895 to 340655 (10:10) in 3:30. Filename: F:\MyFlac\Grateful Dead\American Beauty (Disc 8) (18) (F312BA12)\16 - Truckin' (live).flac
  Insecure  [Pass 1, Ultra 1 to 3, Re-Rip 56 Frames]
  CRC32: 3E085F7C AccurateRip CRC: 76D28E27 (CRCv2) [DiscID: 018-0032b44a-02ac2953-f312ba12-16]
  ** Reached Maximum 3 Unrecoverable Frames For This Track
Insecure Audio from 00:06:00.720 to 00:06:01.026
Insecure Audio from 00:06:01.573 to 00:06:02.186

--------------

1 Tracks Ripped Inaccurately

CueTools Repair Log

Code: [Select]
[CUETools log; Date: 1/22/2013 8:21:14 PM; Version: 2.1.4]
CUETools DB: corrected 5671 errors.
[AccurateRip ID: 0032b1d7-02ac10d6-ee12b912] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
 --  98.8 [D53CE74B] [941B7F64]  
 01  98.8 [E591EA61] [350DD3BC]  
 02  92.8 [830E6AE6] [BC4327D1]  
 03  98.8 [F061E797] [C6F5B6FD]  
 04  98.8 [D39BA09A] [1A0DB1BD]  
 05  95.5 [18218DA2] [F1A5B82D]  
 06  98.1 [DAA5A215] [C2338998]  
 07  98.8 [7FBA6CA2] [E7C0370F]  
 08  98.8 [A0CEF64D] [D778F9A1]  
 09  98.8 [497C07F8] [BBC8C135]  
 10  98.8 [CF4BAC02] [529A01B0]  
 11  88.1 [06C3E623] [14EABFAD]  
 12  98.8 [DE125B96] [E6371276]  
 13  98.8 [68298FD0] [D35192D1]  
 14  98.8 [BA017F2B] [626D1617]  
 15  98.8 [7F3811B2] [20983AFE]  
 16  98.8 [48D48A03] [E57FE25E]  
 17  88.1 [A277CC7E] [C0724206]  
 18  98.8 [FBABF45B] [627480CD]

A CueTools Verify log, since the original repair log was lacking

Code: [Select]
[CUETools log; Date: 1/22/2013 10:52:02 PM; Version: 2.1.4]
HDCD: peak extend: none, transient filter: none, gain: none
[CTDB TOCID: 8XnHDF2UU1qdTG7jFlK0ZBgdRTQ-] found.
Track | CTDB Status
  1  | (4/4) Accurately ripped
  2  | (4/4) Accurately ripped
  3  | (4/4) Accurately ripped
  4  | (4/4) Accurately ripped
  5  | (4/4) Accurately ripped
  6  | (4/4) Accurately ripped
  7  | (4/4) Accurately ripped
  8  | (4/4) Accurately ripped
  9  | (4/4) Accurately ripped
 10  | (4/4) Accurately ripped
 11  | (3/4) Accurately ripped
 12  | (3/4) Accurately ripped
 13  | (4/4) Accurately ripped
 14  | (4/4) Accurately ripped
 15  | (3/4) Accurately ripped
 16  | (3/4) Accurately ripped
 17  | (4/4) Accurately ripped
 18  | (4/4) Accurately ripped
[AccurateRip ID: 0032b1d7-02ac10d6-ee12b912] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
 --  98.8 [D53CE74B] [941B7F64]  
 01  98.8 [E591EA61] [350DD3BC]  
 02  92.8 [830E6AE6] [BC4327D1]  
 03  98.8 [F061E797] [C6F5B6FD]  
 04  98.8 [D39BA09A] [1A0DB1BD]  
 05  95.5 [18218DA2] [F1A5B82D]  
 06  98.1 [DAA5A215] [C2338998]  
 07  98.8 [7FBA6CA2] [E7C0370F]  
 08  98.8 [A0CEF64D] [D778F9A1]  
 09  98.8 [497C07F8] [BBC8C135]  
 10  98.8 [CF4BAC02] [529A01B0]  
 11  88.1 [06C3E623] [14EABFAD]  
 12  98.8 [DE125B96] [E6371276]  
 13  98.8 [68298FD0] [D35192D1]  
 14  98.8 [BA017F2B] [626D1617]  
 15  98.8 [7F3811B2] [20983AFE]  
 16  98.8 [48D48A03] [E57FE25E]  
 17  88.1 [A277CC7E] [C0724206]  
 18  98.8 [FBABF45B] [627480CD]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2013-01-23 04:36:55
Could you present an EAC log indicating the disc's TOC?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-01-23 12:11:08
EAC Burst Mode Extraction Log from disc above

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 23. January 2013, 7:08

Grateful Dead / American Beauty

Used drive  : PLEXTOR CD-R  PREMIUM  Adapter: 4  ID: 2

Read mode : Burst

Read offset correction                      : 30
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Not detected, thus appended to previous track

Performing a test extraction only


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.33 |  5:18.52 |        33    |    23934 
        2  |  5:19.10 |  3:24.50 |    23935    |    39284 
        3  |  8:43.60 |  3:19.25 |    39285    |    54234 
        4  | 12:03.10 |  2:25.58 |    54235    |    65167 
        5  | 14:28.68 |  6:13.62 |    65168    |    93204 
        6  | 20:42.55 |  4:09.70 |    93205    |  111949 
        7  | 24:52.50 |  4:09.00 |    111950    |  130624 
        8  | 29:01.50 |  3:09.03 |    130625    |  144802 
        9  | 32:10.53 |  5:14.20 |    144803    |  168372 
      10  | 37:24.73 |  5:17.65 |    168373    |  192212 
      11  | 42:42.63 |  3:17.17 |    192213    |  207004 
      12  | 46:00.05 |  4:21.68 |    207005    |  226647 
      13  | 50:21.73 |  5:18.10 |    226648    |  250507 
      14  | 55:40.08 |  3:20.47 |    250508    |  265554 
      15  | 59:00.55 |  6:31.15 |    265555    |  294894 
      16  | 65:31.70 | 10:10.10 |    294895    |  340654 
      17  | 75:42.05 |  3:01.58 |    340655    |  354287 
      18  | 78:43.63 |  1:10.37 |    354288    |  359574 


Track  1

    Filename C:\Test Flac Rips\American Beauty\01 - Box of Rain.wav

    Timing problem 0:01:43

    Peak level 98.8 %
    Extraction speed 15.5 X
    Test CRC E591EA61
    Accurately ripped (confidence 12)  [C3B69A41]  (AR v2)
    Copy finished

Track  2

    Filename C:\Test Flac Rips\American Beauty\02 - Friend of the Devil.wav

    Peak level 92.8 %
    Extraction speed 17.1 X
    Test CRC 830E6AE6
    Accurately ripped (confidence 12)  [548A053D]  (AR v2)
    Copy OK

Track  3

    Filename C:\Test Flac Rips\American Beauty\03 - Sugar Magnolia.wav

    Peak level 98.8 %
    Extraction speed 18.2 X
    Test CRC F061E797
    Accurately ripped (confidence 12)  [3B451526]  (AR v2)
    Copy OK

Track  4

    Filename C:\Test Flac Rips\American Beauty\04 - Operator.wav

    Peak level 98.8 %
    Extraction speed 19.2 X
    Test CRC D39BA09A
    Accurately ripped (confidence 12)  [5B514972]  (AR v2)
    Copy OK

Track  5

    Filename C:\Test Flac Rips\American Beauty\05 - Candyman.wav

    Peak level 95.5 %
    Extraction speed 20.4 X
    Test CRC 18218DA2
    Accurately ripped (confidence 12)  [EF3D0B59]  (AR v2)
    Copy OK

Track  6

    Filename C:\Test Flac Rips\American Beauty\06 - Ripple.wav

    Peak level 98.1 %
    Extraction speed 21.9 X
    Test CRC DAA5A215
    Accurately ripped (confidence 12)  [2AF0E967]  (AR v2)
    Copy OK

Track  7

    Filename C:\Test Flac Rips\American Beauty\07 - Brokedown Palace.wav

    Peak level 98.8 %
    Extraction speed 23.0 X
    Test CRC 7FBA6CA2
    Accurately ripped (confidence 12)  [CC771906]  (AR v2)
    Copy OK

Track  8

    Filename C:\Test Flac Rips\American Beauty\08 - Till the Morning Comes.wav

    Peak level 98.8 %
    Extraction speed 23.9 X
    Test CRC A0CEF64D
    Accurately ripped (confidence 12)  [13BBA324]  (AR v2)
    Copy OK

Track  9

    Filename C:\Test Flac Rips\American Beauty\09 - Attics of My Life.wav

    Peak level 98.8 %
    Extraction speed 24.9 X
    Test CRC 497C07F8
    Accurately ripped (confidence 12)  [808FE9A0]  (AR v2)
    Copy OK

Track 10

    Filename C:\Test Flac Rips\American Beauty\10 - Truckin’.wav

    Peak level 98.8 %
    Extraction speed 26.1 X
    Test CRC CF4BAC02
    Accurately ripped (confidence 12)  [712C39DD]  (AR v2)
    Copy OK

Track 11

    Filename C:\Test Flac Rips\American Beauty\11 - Truckin’ (single version).wav

    Peak level 88.1 %
    Extraction speed 27.1 X
    Test CRC 06C3E623
    Accurately ripped (confidence 12)  [E9A485A2]  (AR v2)
    Copy OK

Track 12

    Filename C:\Test Flac Rips\American Beauty\12 - Friend of the Devil (live).wav

    Peak level 98.8 %
    Extraction speed 27.9 X
    Test CRC DE125B96
    Accurately ripped (confidence 12)  [AAB195F5]  (AR v2)
    Copy OK

Track 13

    Filename C:\Test Flac Rips\American Beauty\13 - Candyman (live).wav

    Peak level 98.8 %
    Extraction speed 28.9 X
    Test CRC 68298FD0
    Accurately ripped (confidence 12)  [CF3107A1]  (AR v2)
    Copy OK

Track 14

    Filename C:\Test Flac Rips\American Beauty\14 - Till the Morning Comes (live).wav

    Peak level 98.8 %
    Extraction speed 29.7 X
    Test CRC BA017F2B
    Accurately ripped (confidence 12)  [D0F044D0]  (AR v2)
    Copy OK

Track 15

    Filename C:\Test Flac Rips\American Beauty\15 - Attics of My Life (live).wav

    Peak level 98.8 %
    Extraction speed 30.7 X
    Test CRC 7F3811B2
    Accurately ripped (confidence 12)  [E172D235]  (AR v2)
    Copy OK

Track 16

    Filename C:\Test Flac Rips\American Beauty\16 - Truckin’ (live).wav

    Peak level 98.8 %
    Extraction speed 32.3 X
    Test CRC 48D48A03
    Accurately ripped (confidence 12)  [37F14D0B]  (AR v2)
    Copy OK

Track 17

    Filename C:\Test Flac Rips\American Beauty\17 - Ripple (alternate take).wav

    Peak level 88.1 %
    Extraction speed 33.4 X
    Test CRC A277CC7E
    Accurately ripped (confidence 12)  [2837EA7B]  (AR v2)
    Copy OK

Track 18

    Filename C:\Test Flac Rips\American Beauty\18 - American Beauty Radio Spot.wav

    Peak level 98.8 %
    Extraction speed 34.0 X
    Test CRC 88D26BE7
    Accurately ripped (confidence 12)  [6408B07F]  (AR v2)
    Copy OK


All tracks accurately ripped

No errors occurred

End of status report

==== Log checksum CC2EEA719C67FC07C7A765ACFD0B3ABC30A8BCE36228C9E0A63579651907EF97 ====
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-23 12:55:23
Start sector: 33

CUETools doesn't know that, and it needs to know it to access AR.
Unfortunately, it cannot support dbPowerAMP extraction log, so it cannot find this information.
You can specify it manually (Pregap: 00:00:33)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-01-23 15:37:12
Start sector: 33

CUETools doesn't know that, and it needs to know it to access AR.
Unfortunately, it cannot support dbPowerAMP extraction log, so it cannot find this information.
You can specify it manually (Pregap: 00:00:33)


Thanks. Any ETA on reading CD-TOC from tags as implemented in dBpoweramp? I take it that would have fixed this problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tubebend on 2013-01-26 23:49:50
Hi!

I still had problems with the missing CTDB log in EAC. For example for a two-disc release I got the log for only the first disc... After many tryouts without any comprehensible results I nearly gave up - but finally updated - as a last-ditch attempt - the CTDB-EAC-plugin from version 2.1.3 to 2.1.4. And now everything works fine. Thanks for the hints I foolishly followed too late... 

Cheers, Tubebend
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DT5 on 2013-01-27 09:27:39
Probably a good idea. Although the best solution would probably be to convince Andre to add support for such additional metadata fields in EAC, for example to let the plugin manipulate Vorbis comment fields directly - then there would be no need to use Picard


Is Andre still developing the program?
No update for a while and he is also not present in his forum for a while.

So instead of ripping all my discs with EAC I changed my habits and rip now more than 90% of my discs with CUEripper

But I miss in the CUEripper log something like the range quality value.
You know how often you had to rerip sectors on the CD. Wouldn't it be possible to add something similar too?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ThePampers on 2013-01-27 10:39:07
Good question... EAC is still in development ?
I do not think, Andre missing from the forum for a year and half...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ThePampers on 2013-01-27 10:41:28
But anyway... any news about new Cuetools version (2.1.5 i suppose) ??
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-28 00:31:43
But I miss in the CUEripper log something like the range quality value.
You know how often you had to rerip sectors on the CD. Wouldn't it be possible to add something similar too?

CUERipper doesn't keep track of how many retries it made at a given sector, but it does keep track of the sectors where it wasn't satisfied with the results, i.e. where the number of retries reach maximum allowed. It displays this information in the log file (suspicious sectors). I could easily convert the number of suspicious sectors into some kind of e.g. logarithmic quality percentage, like 100% for 0 suspicious sectors, 95% for 1, 90% for 2, 85% for 4, 80% for 8 etc.

In EAC quality means something different, i suppose. It's probably not about sectors that reached maximum allowed number of retries, but about sectors that had more than minimum allowed number of retries. I wonder if it's relevant.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-01-28 00:41:11
But anyway... any news about new Cuetools version (2.1.5 i suppose) ??


Not at the moment, no. I'm quite busy at my day job, so the amount of time that i have to spare for CUETools is mostly spent on CTDB maintenance. CUETools 2.1.4 release appears to be quite robust and i am not aware of any urgent issues with it, so 2.1.5 can wait.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-02-01 19:23:02
Is there any way to use CueTools to encode to Wavpack Hybrid (Lossy+Correction)?

I tried to set up a 'custom' encoder command line (wavpack.exe / -b320 -hx -m -c - %O) but nothing happens: the progress bar is stuck at 0% and the wavpack process has to be killed...
This is what I've been trying to do and there doesn't seems to be any way to do that... any chance of this being possible in the future? I actually expected the "hybrid" option to be specifically for wavpack, but it combines it with lossywav, apparently.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-02-02 00:44:58
This appears to do what HotShotFR was trying to do.
ref: CUETools Advanced Settings: Encoders (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Encoders)

Extension: wv
Path: wavpack.exe (wavpack.exe (http://www.wavpack.com/downloads.html) copied to CUETools folder)
Parameters: -hb%Mx -c -m - %O
Modes: 256 320
Name: wv_hybrid

Creates hybrid .wv and .wvc correction files.
[edit]: .wv is registered in CUETools as a 'lossless' encoder so that's where you'll find 'wv_hybrid' for encoding.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: high_rockin on 2013-02-06 14:43:57
Hi,

My CUERipper usually raise Exception: Error reading CD: unknown error
when I use a drive connected via SATA/IDE to USB converter cable.

I tried on LG GH24NS95(SATA) and NEC ND-3520A(IDE).

This error appears randomly, so ripping process of same disc sometimes succeeds and sometimes fails at various points.
Although it must be due to the connection abnormality,
I have never encountered similar error on other rippers like EAC, dbPowerAmp or foobar2000.
So, I hope this problem can be solved by CUERipper's enhancement.

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2013-02-06 15:24:07
high_rockin:

USB (and firewire) bridges sometimes do weird things – myself I am using dBpoweramp, and it turns out that it cannot get out C2 error pointers from my firewire-connected CD changer although EAC can.  I can only guess that issues are so much idiosyncratic that some combinations of software/firmware/hardware work and others don't. From my (limited) understanding, the issue can be either related to the converter cable or also to the motherboard chip.

It is likely better, if you can, to connect by SATA (or eSATA, equivalently). If you have e.g. a laptop with ExpressCard, then you can get the connection for less than $10 at eBay. Worth it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tev777 on 2013-02-06 15:32:36
Sorry for not parsing all 85 pages of this thread for an answer...

Right now it seems that CueRipper applies Ape2 tags to True Audio files instead of ID3. Is there a way to correct this in the settings? I've looked, but I did not find anything.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-02-06 17:25:40
No, CUERipper uses taglib sharp for ID3.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xedge on 2013-02-07 21:48:21
CUETools & Quicktime (QT AAC)

Ive been using cueripper for ripping cd's to flac
now i want to encode these flac's to AAC

http://www.cuetools.net/wiki/CUETools_Adva...encoder_options (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Encoders#External_encoder_options)
Path is easy enough
however, what is required for;
Parameters
Modes

& how are the QT settings then controlled, eg bitrate



i wish to use QT as reading around, it seems to be the best AAC encoder, & the most up to date

thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-02-08 00:04:55
QAAC (https://sites.google.com/site/qaacpage/news) is up to date.

Well to use QTAACENC, you need to decide if you want to use
--cbr, --abr, --cvbr, or --tvbr (reference (http://tmkk.undo.jp/qtaacenc/))
or setup a separate encoder for each.

One example might be (Sorry, I don't have Quicktime installed so I did not test this)

Extension: m4a
Path: qtaacenc.exe (qtaacenc.exe copied to CUETools folder)
Parameters: --tvbr %M --high - %O
Modes: 10 20 30 40 50 60 70 80 90 100 110 127
Name: qtaac tvbr
Lossless: uncheck this box

Encoder mode {slider} (http://www.cuetools.net/wiki/CUETools_Settings#.289.29_Audio_Output_.7Bsection.7D) lets you select the quality modes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sidjames on 2013-02-09 22:59:52
hi, hope this hasnt been brought up already but noticed an issue with how cuetools 2.14 works with multiple discs - if you have a collection with more than 5 discs - any discs with a (foobar written) disc number tag over 5 are grouped together as "disc 5"... you probably have to have all the files in the same directory to notice this..

example :

5cd set ripped into the same directory, each disc is tagged as such and has own log file

- processed as normal, no problems

6cd set..

- first 4 cds fine, 5th and 6th grouped together

i have the "mindrocker" (60s psychedelia) compilation on my hd (13cds) and it shows up within the multiselect browser window as 5cds..

cd1.. 14 files
cd2.. 14 files
cd3.. 14 files
cd4.. 14 files
cd5.. 140 files..

should also point out that i dont have cue files for any of these discs, perhaps that is part of the problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-02-09 23:57:43
Grouping based on tags limited to 5 is documented (http://www.cuetools.net/wiki/CUETools_Settings#.286.29_CUE_Paths_.7Bsection.7D). CUEs would definitely help.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-02-10 22:27:10
This appears to do what HotShotFR was trying to do.
ref: CUETools Advanced Settings: Encoders (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Encoders)

Extension: wv
Path: wavpack.exe (wavpack.exe (http://www.wavpack.com/downloads.html) copied to CUETools folder)
Parameters: -hb%Mx -c -m - %O
Modes: 256 320
Name: wv_hybrid

Creates hybrid .wv and .wvc correction files.
[edit]: .wv is registered in CUETools as a 'lossless' encoder so that's where you'll find 'wv_hybrid' for encoding.

Thanks, I was kind of fixed on the whole built-in encoders concept so I forgot I can also use an external encoder
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ripdog on 2013-02-25 07:00:24
Any chance of an improvement in CUETools' handling of non-ASCII file/folder names? I used CUETools to split a number of my japanese flac/cue files, and all the filenames came out as ______. (At least for the japanese characters.) Example CUE: http://pastie.org/6332223 (http://pastie.org/6332223)

The encoding was UTF-8, and windows is perfectly capable of having such characters copypasted into the filenames, and CUETools did transfer the tags correctly.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-02-25 12:53:45
http://www.cuetools.net/wiki/CUETools_Adva...tings:_CUETools (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools) : Force ANSI filenames?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zfox on 2013-03-07 11:35:18
Greg, the latest CUERipper cannot detect drive settings from a PLEXTOR BD-ROM PX-B120U 1.11 (USB). An Exception is thrown when the ripping process initiates. Medium is present.

(http://users.auth.gr/kyriak/temp/cueripper.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-03-21 09:32:04
Since CTDB started per-track verification, all rip results from CUERipper and the EAC plugin are submitted but repair data is only supposed to be accepted for good rips. Per-disc verification can have several (1/x) No match results from rips with some errors by design. Those results are stored to increase confidence levels for the tracks without errors. The detailed log is Off by default so most users should only see the per-track results similar to AR.
CUETools only submits to CTDB if AR confidence is greater than 1 AND no existing entry is found in CTDB.

[EDIT]
You're probably seeing a bad repair submission from the EAC plugin. See CTDB EAC Plugin: Known_issues (http://cuetools.net/wiki/CTDB_EAC_Plugin#Known_issues). Don't trust (1/x) results for repair.
But it could also be an alternate pressing. If I ever get the guide written for the wiki, I have an example of such a disc.

I ripped a scratched CD with EAC. The CTDB plug-in submitted the bad rip, as expected:
Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 21. March 2013, 2:11

Venus Hum / Big Beautiful Sky

Used drive  : PLDS    DVD-RW DH16ABSH  Adapter: 0  ID: 1

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : No

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Not detected, thus appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  4:00.55 |        0    |    18054 
        2  |  4:00.55 |  3:46.70 |    18055    |    35074 
        3  |  7:47.50 |  3:51.63 |    35075    |    52462 
        4  | 11:39.38 |  4:05.40 |    52463    |    70877 
        5  | 15:45.03 |  4:19.72 |    70878    |    90374 
        6  | 20:05.00 |  3:16.70 |    90375    |  105144 
        7  | 23:21.70 |  3:20.23 |    105145    |  120167 
        8  | 26:42.18 |  4:23.10 |    120168    |  139902 
        9  | 31:05.28 |  4:37.62 |    139903    |  160739 
      10  | 35:43.15 |  4:07.40 |    160740    |  179304 
      11  | 39:50.55 |  3:54.33 |    179305    |  196887 
      12  | 43:45.13 |  3:49.17 |    196888    |  214079 
      13  | 50:06.30 |  5:25.14 |    225480    |  249868 


Track  1

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[01] Venus Hum - Hummingbirds.wav

    Peak level 99.9 %
    Extraction speed 5.8 X
    Track quality 99.9 %
    Copy CRC CC117BC9
    Accurately ripped (confidence 2)  [A64BC7C9]  (AR v2)
    Copy OK

Track  2

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[02] Venus Hum - Montana.wav

    Peak level 99.9 %
    Extraction speed 7.6 X
    Track quality 100.0 %
    Copy CRC ECD92270
    Accurately ripped (confidence 2)  [A5BBB289]  (AR v2)
    Copy OK

Track  3

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[03] Venus Hum - Soul Sloshing.wav

    Peak level 99.9 %
    Extraction speed 8.5 X
    Track quality 100.0 %
    Copy CRC B024FA16
    Accurately ripped (confidence 2)  [E5A1EA29]  (AR v2)
    Copy OK

Track  4

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[04] Venus Hum - Wordless May.wav

    Peak level 99.9 %
    Extraction speed 9.2 X
    Track quality 100.0 %
    Copy CRC 58AA8AAD
    Accurately ripped (confidence 2)  [E744AD30]  (AR v2)
    Copy OK

Track  5

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[05] Venus Hum - Alice.wav

    Suspicious position 0:03:19 - 0:03:24

    Peak level 99.9 %
    Extraction speed 2.8 X
    Track quality 98.7 %
    Copy CRC FCA14352
    Cannot be verified as accurate (confidence 27)  [F5A38655], AccurateRip returned [FD2A830B]  (AR v2)
    Copy finished

Track  6

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[06] Venus Hum - Lumberjacks.wav

    Peak level 99.9 %
    Extraction speed 9.9 X
    Track quality 100.0 %
    Copy CRC A0DE05F6
    Accurately ripped (confidence 2)  [21B3171D]  (AR v2)
    Copy OK

Track  7

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[07] Venus Hum - Beautiful Spain.wav

    Peak level 99.9 %
    Extraction speed 10.8 X
    Track quality 100.0 %
    Copy CRC 230A2618
    Accurately ripped (confidence 2)  [BCD1BD5A]  (AR v2)
    Copy OK

Track  8

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[08] Venus Hum - The Bells.wav

    Peak level 99.9 %
    Extraction speed 11.4 X
    Track quality 100.0 %
    Copy CRC E388B1C0
    Accurately ripped (confidence 2)  [8103622F]  (AR v2)
    Copy OK

Track  9

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[09] Venus Hum - Springtime #2.wav

    Peak level 99.9 %
    Extraction speed 11.1 X
    Track quality 100.0 %
    Copy CRC 61436095
    Accurately ripped (confidence 2)  [CEA24984]  (AR v2)
    Copy OK

Track 10

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[10] Venus Hum - Honey.wav

    Peak level 99.9 %
    Extraction speed 12.4 X
    Track quality 100.0 %
    Copy CRC DF87E5C4
    Accurately ripped (confidence 2)  [375E42E5]  (AR v2)
    Copy OK

Track 11

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[11] Venus Hum - Sonic Boom.wav

    Peak level 99.9 %
    Extraction speed 12.8 X
    Track quality 100.0 %
    Copy CRC EB1BD55B
    Accurately ripped (confidence 2)  [222135FC]  (AR v2)
    Copy OK

Track 12

    Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[12] Venus Hum - Bella Luna.wav

    Peak level 99.9 %
    Extraction speed 13.1 X
    Track quality 100.0 %
    Copy CRC DEDB90BA
    Accurately ripped (confidence 2)  [B731197C]  (AR v2)
    Copy OK


11 track(s) accurately ripped
 1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

There were errors

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: 57yKe23QeyaVP_eCU_cTkYq8sIw-] found, Submit result: 57yKe23QeyaVP_eCU_cTkYq8sIw- has been submitted
[d1e028a7] (33/33) Differs in 498 samples @19:04:16,19:05:06-19:05:07,19:05:45,19:06:61,19:06:74-19:07:00,19:07:12-19:07:13,19:07:25-19:07:26,19:08:41-19:08:42,19:09:05-19:09:06,19:09:44
You can use CUETools to repair this rip.


So now CTDB has 8 submissions, 7 of which are identical, presumably good rips, plus my bad one. (not sure if it matters I was using the 2.1.3 plugin)

I then re-ripped it with CUERipper, which also had trouble with the scratched track:
Code: [Select]
[CUETools log; Date: 3/21/2013 2:50:50 AM; Version: 2.1.4]
CD-Extra data track length 05:25:14.
[CTDB TOCID: 57yKe23QeyaVP_eCU_cTkYq8sIw-] found.
Track | CTDB Status
  1  | (9/9) Accurately ripped
  2  | (9/9) Accurately ripped
  3  | (9/9) Accurately ripped
  4  | (9/9) Accurately ripped
  5  | (7/9) Differs in 90 samples @03:20:03,03:20:42,03:22:22-03:22:23,03:23:13,03:30:07, or (1/9) differs in 90 samples @03:20:03,03:20:42,03:22:22-03:22:23,03:23:13,03:30:07
  6  | (9/9) Accurately ripped
  7  | (9/9) Accurately ripped
  8  | (9/9) Accurately ripped
  9  | (9/9) Accurately ripped
 10  | (9/9) Accurately ripped
 11  | (9/9) Accurately ripped
 12  | (9/9) Accurately ripped
[AccurateRip ID: 0015a670-00cc644e-a40d030d] found.
Track  [  CRC  |  V2  ] Status
 01    [12884c66|a64bc7c9] (28+02/30) Accurately ripped
 02    [b3a4581d|a5bbb289] (29+02/31) Accurately ripped
 03    [8716e2e3|e5a1ea29] (28+02/30) Accurately ripped
 04    [1b3000ee|e744ad30] (28+02/30) Accurately ripped
 05    [5a789296|c8fda304] (00+00/29) No match
 06    [c930d756|21b3171d] (28+02/30) Accurately ripped
 07    [b934b899|bcd1bd5a] (27+02/29) Accurately ripped
 08    [12695676|8103622f] (27+02/29) Accurately ripped
 09    [b9a7d402|cea24984] (27+02/29) Accurately ripped
 10    [09fa0c5c|375e42e5] (27+02/29) Accurately ripped
 11    [9a909811|222135fc] (26+02/28) Accurately ripped
 12    [5d405a40|b731197c] (25+02/27) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  99.9 [EB8A4739] [01964A15]         
 01  99.9 [CC117BC9] [73379AF5]         
 02  99.9 [ECD92270] [5F08F957]         
 03  99.9 [B024FA16] [D597085A]         
 04  99.9 [58AA8AAD] [AB8637B3]         
 05  99.9 [9424BF4A] [CB9A1600]         
 06  99.9 [A0DE05F6] [4FA4E9E0]         
 07  99.9 [230A2618] [FAF190F3]         
 08  99.9 [E388B1C0] [F001FAF1]         
 09  99.9 [61436095] [74AE5D1A]         
 10  99.9 [DF87E5C4] [97298B19]         
 11  99.9 [EB1BD55B] [45D1D6CF]         
 12  99.9 [DEDB90BA] [6FBC05BE]         

I should've made a note of what the post-rip dialog said. I believe it said something about differing in 90 samples, something submitted... so it seems bad rips can be submitted from CUERipper? Meaning there are now 9 submissions (7 good, 2 bad) (plus 1 with no data track):

http://db.cuetools.net/?tocid=57yKe23QeyaVP_eCU_cTkYq8sIw- (http://db.cuetools.net/?tocid=57yKe23QeyaVP_eCU_cTkYq8sIw-)

Both rippers said I could maybe repair the rip with CUETools, so I attempted to do so by dragging the CUERipper rip's .cue file into CUETools, selecting Encode/repair, Tracks, Lossless/flac.

But CUETools won't do anything. After it verifies the tracks, it doesn't prompt me or anything. It just says, in the log section:

Code: [Select]
I:\New folder\Venus Hum\2003 - Big Beautiful Sky\Venus Hum - Big Beautiful Sky.cue: differs in 90 samples, confidence 7, or differs in 90 samples, confidence 1, or verified OK, confidence 1.

How can I make it repair this rip to match the 7 presumably good submissions?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-03-21 11:59:03
There is a known problem where it wouldn't do anything, because repair doesn't work in batch mode (drag and drop mode, or multiselect file browser, or when selecting a folder).
Just hide the browser or switch folder browser.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-24 19:35:59
Two questions:

- is offset correction "harmless", as in, does it change something audible? If not, why would I want to do it?
- CUETools doesn't seem to support foobar's %album artist%. Does it

This appears to do what HotShotFR was trying to do.
ref: CUETools Advanced Settings: Encoders (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Encoders)

Extension: wv
Path: wavpack.exe (wavpack.exe (http://www.wavpack.com/downloads.html) copied to CUETools folder)
Parameters: -hb%Mx -c -m - %O
Modes: 256 320
Name: wv_hybrid

Creates hybrid .wv and .wvc correction files.
[edit]: .wv is registered in CUETools as a 'lossless' encoder so that's where you'll find 'wv_hybrid' for encoding.
Coming back to this, I'm pretty close to what I wanted to achieve, but there are a few problems. I'm going from one file with embedded cuesheet -> separate tracks, this leads to following output

- separate tracks with their respective .wvc
- the tracks don't have any tags beyond %album% and %artist% in them
- there seems to be no way to define a naming scheme for the tracks, only for the cuesheet itself
- the cuesheet is not written in utf-8 even though the internal cue was utf-8 (need this for all the foreign characters, rus/jpn)
- the cuesheet is messed up for the second track (resulting in an unparseable cue), for example:
Code: [Select]
REM GENRE "Rock"
REM DATE 1991
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Alice Cooper"
TITLE "Hey Stoopid"
REM REPLAYGAIN_ALBUM_GAIN -6.45 dB
REM REPLAYGAIN_ALBUM_PEAK 0.972931
FILE "01. Hey Stoopid.wv" WAVE
  TRACK 01 AUDIO
    TITLE "Hey Stoopid"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Love's A Loaded Gun"
    INDEX 00 04:32:56
FILE "02. Love's A Loaded Gun.wv" WAVE
    INDEX 01 00:00:00
  TRACK 03 AUDIO
    TITLE "Snakebite"
    INDEX 00 04:09:47
FILE "03. Snakebite.wv" WAVE
    INDEX 01 00:00:00
  TRACK 04 AUDIO
    TITLE "Burning Our Bed"
    INDEX 00 04:31:29
FILE "04. Burning Our Bed.wv" WAVE
    INDEX 01 00:00:00
  TRACK 05 AUDIO
    TITLE "Dangerous Tonight"
    INDEX 00 04:32:71
FILE "05. Dangerous Tonight.wv" WAVE
    INDEX 01 00:00:00
  TRACK 06 AUDIO
    TITLE "Might As Well Be On Mars"
    INDEX 00 04:40:02
FILE "06. Might As Well Be On Mars.wv" WAVE
    INDEX 01 00:00:00
  TRACK 07 AUDIO
    TITLE "Feed My Frankenstein"
    INDEX 00 07:07:46
FILE "07. Feed My Frankenstein.wv" WAVE
    INDEX 01 00:00:00
  TRACK 08 AUDIO
    TITLE "Hurricane Years"
    INDEX 00 04:42:72
FILE "08. Hurricane Years.wv" WAVE
    INDEX 01 00:00:00
  TRACK 09 AUDIO
    TITLE "Little By Little"
    INDEX 00 03:56:71
FILE "09. Little By Little.wv" WAVE
    INDEX 01 00:00:00
  TRACK 10 AUDIO
    TITLE "Die For You"
    INDEX 00 04:33:34
FILE "10. Die For You.wv" WAVE
    INDEX 01 00:00:00
  TRACK 11 AUDIO
    TITLE "Dirty Dreams"
    INDEX 00 04:15:04
FILE "11. Dirty Dreams.wv" WAVE
    INDEX 01 00:00:00
  TRACK 12 AUDIO
    TITLE "Wind-Up Toy"
    INDEX 00 03:27:59
FILE "12. Wind-Up Toy.wv" WAVE
    INDEX 01 00:00:00

Any ideas? I'd rather not re-tag the whole library after conversion...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-03-24 19:57:50
- offset correction is _ almost_ harmless - it might loose some samples at the beginning or end (depending on whether offset is positive or negative), number of lost samples equals offset, but in 99% of cases those samples would be null  anyway. But as i explained several times here, i don't see any reason to do this.
- CUETools does support "album artist", but this tag is only written if track artists are specified and differ from album artist.
- the naming scheme for tracks should be defined in "Track format" option.
- utf8 is used when cuesheet has characters that are missing in your default codepage, e.g. if you have Russian Windows version, utf8 will be used for Japanese, but not for Russian.
- the cue-sheet is not messed up, it's called "Gaps appended/non-compliant". You can try using "Gaps prepended" if you want fb2k to read it, but that would also change your audio files - they will contain silence before tracks, not after tracks, which might not be what you want. Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2013-03-24 20:21:18
Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.

Seriously, this!

A cue sheet is a cue sheet, not a playlist.  If you need a playlist, use a playlist.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-24 20:29:49
Thanks for the fast response,

- CUETools does support "album artist", but this tag is only written if track artists are specified and differ from album artist.
I see. I guess there is no possibility of writing something like %album artist%[ ?%track artist%] as output then?

Quote
- the naming scheme for tracks should be defined in "Track format" option.
Found it, thanks!

Quote
- utf8 is used when cuesheet has characters that are missing in your default codepage, e.g. if you have Russian Windows version, utf8 will be used for Japanese, but not for Russian.
Hmm well, my codepage for non-unicode programs is set to Japanese, so I guess that's why it doesn't use UTF-8. For compatibility reasons though, it'd be nice to have an option to force it to use UTF-8 all the time...

Quote
- the cue-sheet is not messed up, it's called "Gaps appended/non-compliant". You can try using "Gaps prepended" if you want fb2k to read it, but that would also change your audio files - they will contain silence before tracks, not after tracks, which might not be what you want. Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.
I guess I just don't understand the format of it then, to me it looks like it groups 2 first tracks together to one and shifts the rest. The cuesheets CUERipper creates don't have this format even though I configured it to keep HTOA. I must be misunderstanding something here, I don't see why this format is needed when converting from single file -> separate tracks when it was not needed to preserver the HTOA/gaps when I ripped the CD...

Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.

Seriously, this!

A cue sheet is a cue sheet, not a playlist.  If you need a playlist, use a playlist.
As long as that cuesheet can still be used to burn the CD back perfectly, all is fine. I didn't plan to use it as a playlist, I was just confused since it's the first time I saw a non-compliant cuesheet.

edit: Any idea about track tags? Can I get it to put title/replaygain info from the embedded cuesheet into the separate tracks?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-03-24 22:03:31
I see. I guess there is no possibility of writing something like %album artist%[ ?%track artist%] as output then?

I thought we were talking about tags. If we're talking about filenames, %artist% means different things in output path format and in track format. In the first case it means album artist, in the second case - track artist.
For example, you might have output path format "%music%\%artist%\[%year% - ]%album%[' ('%unique%')']\%artist% - %album%.cue" and track format "%tracknumber%.[ %artist% -] %title%".
You will get files like "C:\Users\user\Music\Various Artists\1990 - Greatest Hits\Various Artists - Greatest Hits.cue" and "C:\Users\user\Music\Various Artists\1990 - Greatest Hits\01. Abba - Mamma Mia.wv".

For compatibility reasons though, it'd be nice to have an option to force it to use UTF-8 all the time...

This might be a good idea.

I don't see why this format is needed when converting from single file -> separate tracks when it was not needed to preserver the HTOA/gaps when I ripped the CD...

It is needed when there are gaps between tracks. Not all CDs have gaps. Also, CUERipper might for some reason be unable to detect gaps with your drive.

edit: Any idea about track tags? Can I get it to put title/replaygain info from the embedded cuesheet into the separate tracks?

CUETools doesn't transfer replay gain. Those tags are nonstandard, and would probably have to be recalculated anyway after splitting album into tracks - individual tracks might have a different gain compared to the whole album.
As for the track title, it should have been transferred, unless you disabled it by unchecking "Write basic tags from CUE data".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-25 00:19:29
It is needed when there are gaps between tracks. Not all CDs have gaps. Also, CUERipper might for some reason be unable to detect gaps with your drive.
This seems to be the case I guess. I do remember some kind of gap related error, but that was on a scratched CD. Is correct gap detection not related to AR/CTDB results? How can I test if it's detecting the gaps correctly?

Here's the internal .cue CUERipper created for comparison
Code: [Select]
REM GENRE Rock
REM DATE 1991
REM COMMENT ExactAudioCopy v0.99pb4
PERFORMER "Alice Cooper"
TITLE "Hey Stoopid"
REM REPLAYGAIN_ALBUM_GAIN -6.45 dB
REM REPLAYGAIN_ALBUM_PEAK 0.972931
FILE "DUMMY" WAVE
  TRACK 01 AUDIO
    TITLE "Hey Stoopid"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Love's A Loaded Gun"
    INDEX 00 04:32:56
    INDEX 01 04:34:37
  TRACK 03 AUDIO
    TITLE "Snakebite"
    INDEX 00 08:44:09
    INDEX 01 08:45:65
  TRACK 04 AUDIO
    TITLE "Burning Our Bed"
    INDEX 00 13:17:19
    INDEX 01 13:19:00
  TRACK 05 AUDIO
    TITLE "Dangerous Tonight"
    INDEX 00 17:51:71
    INDEX 01 17:53:52
  TRACK 06 AUDIO
    TITLE "Might As Well Be On Mars"
    INDEX 00 22:33:54
    INDEX 01 22:35:35
  TRACK 07 AUDIO
    TITLE "Feed My Frankenstein"
    INDEX 00 29:43:06
    INDEX 01 29:44:62
  TRACK 08 AUDIO
    TITLE "Hurricane Years"
    INDEX 00 34:27:59
    INDEX 01 34:29:40
  TRACK 09 AUDIO
    TITLE "Little By Little"
    INDEX 00 38:26:36
    INDEX 01 38:28:17
  TRACK 10 AUDIO
    TITLE "Die For You"
    INDEX 00 43:01:51
    INDEX 01 43:03:32
  TRACK 11 AUDIO
    TITLE "Dirty Dreams"
    INDEX 00 47:18:36
    INDEX 01 47:20:17
  TRACK 12 AUDIO
    TITLE "Wind-Up Toy"
    INDEX 00 50:48:01
    INDEX 01 50:49:57
Doesn't this one handle gaps as well? I always thought that the index 00/01 was exactly for that :x

Quote
CUETools doesn't transfer replay gain. Those tags are nonstandard, and would probably have to be recalculated anyway after splitting album into tracks - individual tracks might have a different gain compared to the whole album.
As for the track title, it should have been transferred, unless you disabled it by unchecking "Write basic tags from CUE data".
I'm kinda noticing my whole options are messed up for some reason.   
The option was indeed unchecked. I guess recalculating replay gain is not a big problem, it's usually fast. The tags shouldn't change though, foobar calculates both track and album gain, those values are still valid since the tracks still represent one album.

What does %unique% do exactly btw?
Thanks for your patience ^^;
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-03-25 00:43:28
How can I test if it's detecting the gaps correctly?
Here's the internal .cue CUERipper created for comparison

This CUE-sheet has sane INDEX 00 entries, which means that CUERipper is detecting the gaps correctly.
This CUE-sheet is from a single-file disc image. Non-compliant cue-sheets are for file-per-track gaps-appended rips. Gaps-prepended cue-sheet would look more like a single-file one, but there are other problems with gaps-prepended rips. For example, when you select a track in a player and click "play", you might have to listen to the ending of the previous track first.

What does %unique% do exactly btw?

It makes sure that if the target file already exists, a new folder is created.
This might happen if you have a two disc release or several remasters of the same album, or just several rips of the same disc.
It's not very useful when you are processing a single album - you might prefer to see a warning dialog that tells you that file already exists instead. That's what happens if you remove %unique% from your path template.
But when you are batch-processing a lot of albums, you might want to make sure each one will end up in a different folder instead of just being skipped.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-25 00:59:47
I think I understand now, thanks. Seeing as ImgBurn seems to parse the non-compliant cuesheet correctly, I can just safely ignore the fact foobar can't parse it - I guess the reason being that you don't need a .cue for playback if you have separate tracks anyway. And converting back to a single file "restores" the single file version, so it's all good.

Now to decide if I really want to change my storage scheme and format

edit: though I probably wait till you have the time to add that "force utf-8" option, if you do.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eleria on 2013-03-25 10:53:28
Hello, I have a little problem.
My drive is recognized by accuraterip as having a +667 offset (it's true at 100% according to thousands of drive records), there is 1 CTDB and 2 AccurateripDB records, and the log tells me

Code: [Select]
Track cannot be verified as accurate (confidence 2)  [A2616C17], AccurateRip returned [F9186714]

Then
Code: [Select]
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

At the end of the ripping sequence I got a popup saying that the data was sent to CTDB and that the rip would be OK if I had an offset of 664 not 667.

I've never had such case so I don't know what to do, should I consider MY rip is accurate and the other one isn't ?
I mean my drive can't have a different offset than accuraterip says because I've ripped quite a few other CDs and both CTDB and AccurateDB always said my rip were accurate.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-25 12:12:07
Likely just a different pressing (http://wiki.hydrogenaudio.org/index.php?title=AccurateRip#Pressings) than the one in the AR database. Your rip is probably accurate but I'd need to see the full log(s).
Your drive offset should be correct at +667.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eleria on 2013-03-25 13:33:46
Thanks for the reply, here are 3 logs including the problematic one which is the last.

Code: [Select]
CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 16. November 2012, 15:51

At the Drive-In / Relationship of Command

Used drive  : HL-DT-ST DVDRAM GH22NS50   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  2:55.07 |         0    |    13131  
        2  |  2:55.07 |  3:17.60 |     13132    |    27966  
        3  |  6:12.67 |  4:19.73 |     27967    |    47464  
        4  | 10:32.65 |  3:27.35 |     47465    |    63024  
        5  | 14:00.25 |  6:05.20 |     63025    |    90419  
        6  | 20:05.45 |  3:02.72 |     90420    |   104141  
        7  | 23:08.42 |  5:01.08 |    104142    |   126724  
        8  | 28:09.50 |  2:55.37 |    126725    |   139886  
        9  | 31:05.12 |  5:24.65 |    139887    |   164251  
       10  | 36:30.02 |  3:23.08 |    164252    |   179484  
       11  | 39:53.10 |  5:34.15 |    179485    |   204549  
       12  | 45:27.25 |  4:00.47 |    204550    |   222596  
       13  | 49:27.72 |  4:13.10 |    222597    |   241581  


Range status and errors

Selected range

     Filename C:\Users\Luthee\Music\At the Drive-In - Relationship of Command - 2000\At the Drive-In - Relationship of Command.wav

     Peak level 99.9 %
     Range quality 100.0 %
     Test CRC 2505FC11
     Copy CRC 2505FC11
     Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 19)  [F631A120]
Track  2  accurately ripped (confidence 19)  [18852F53]
Track  3  accurately ripped (confidence 19)  [02AD2E58]
Track  4  accurately ripped (confidence 19)  [E919CB93]
Track  5  accurately ripped (confidence 19)  [967FF13E]
Track  6  accurately ripped (confidence 19)  [40902E96]
Track  7  accurately ripped (confidence 18)  [A8CDF656]
Track  8  accurately ripped (confidence 18)  [0C01D025]
Track  9  accurately ripped (confidence 19)  [FD3D5565]
Track 10  accurately ripped (confidence 19)  [C7C865D2]
Track 11  accurately ripped (confidence 18)  [2A360003]
Track 12  accurately ripped (confidence 18)  [6247A558]
Track 13  accurately ripped (confidence 17)  [C5DC9BF1]

All tracks accurately ripped

End of status report


Code: [Select]
CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 8. November 2012, 14:46

Pin-Up Went Down / 2 Unlimited

Used drive  : HL-DT-ST DVDRAM GH22NS50   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  1:36.50 |         0    |     7249  
        2  |  1:36.50 |  3:18.37 |      7250    |    22136  
        3  |  4:55.12 |  3:50.15 |     22137    |    39401  
        4  |  8:45.27 |  4:07.46 |     39402    |    57972  
        5  | 12:52.73 |  2:21.48 |     57973    |    68595  
        6  | 15:14.46 |  5:30.45 |     68596    |    93390  
        7  | 20:45.16 |  2:37.63 |     93391    |   105228  
        8  | 23:23.04 |  2:42.60 |    105229    |   117438  
        9  | 26:05.64 |  1:33.12 |    117439    |   124425  
       10  | 27:39.01 |  4:34.47 |    124426    |   145022  
       11  | 32:13.48 |  3:04.71 |    145023    |   158893  
       12  | 35:18.44 |  3:15.35 |    158894    |   173553  
       13  | 38:34.04 |  3:32.39 |    173554    |   189492  


Range status and errors

Selected range

     Filename C:\Users\Luthee\Music\Pin-Up Went Down\2008 - 2 Unlimited\Pin-Up Went Down - 2 Unlimited.wav

     Peak level 100.0 %
     Range quality 100.0 %
     Test CRC 43E7AD84
     Copy CRC 43E7AD84
     Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 4)  [5045D70C]
Track  2  accurately ripped (confidence 4)  [D5625C27]
Track  3  accurately ripped (confidence 4)  [3334CED0]
Track  4  accurately ripped (confidence 4)  [6EBEEE8B]
Track  5  accurately ripped (confidence 4)  [016BB552]
Track  6  accurately ripped (confidence 4)  [28741680]
Track  7  accurately ripped (confidence 4)  [1FB50058]
Track  8  accurately ripped (confidence 4)  [529E605C]
Track  9  accurately ripped (confidence 4)  [60D0D6E4]
Track 10  accurately ripped (confidence 4)  [CC93B6CB]
Track 11  accurately ripped (confidence 4)  [7A48C17B]
Track 12  accurately ripped (confidence 4)  [1FF38C77]
Track 13  accurately ripped (confidence 4)  [33588998]

All tracks accurately ripped

End of status report


Last, this is the problematic one :

Code: [Select]
CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 25. March 2013, 11:10

Deja Vu / Baroque in the Future

Used drive  : HL-DT-ST DVDRAM GH22NS50   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  3:50.42 |         0    |    17291  
        2  |  3:50.42 |  5:52.25 |     17292    |    43716  
        3  |  9:42.67 |  3:33.34 |     43717    |    59725  
        4  | 13:16.26 |  5:29.54 |     59726    |    84454  
        5  | 18:46.05 |  3:42.67 |     84455    |   101171  
        6  | 22:28.72 |  6:37.64 |    101172    |   131010  
        7  | 29:06.61 |  7:53.15 |    131011    |   166500  
        8  | 37:00.01 |  5:50.13 |    166501    |   192763  
        9  | 42:50.14 |  8:06.13 |    192764    |   229226  


Range status and errors

Selected range

     Filename C:\Users\Luthee\Music\Deja Vu - Baroque in the Future - 1988\Deja Vu - Baroque in the Future.wav

     Peak level 96.6 %
     Range quality 100.0 %
     Test CRC 62B2D3F3
     Copy CRC 62B2D3F3
     Copy OK

No errors occurred


AccurateRip summary

Track  1  cannot be verified as accurate (confidence 2)  [A2616C17], AccurateRip returned [F9186714]
Track  2  cannot be verified as accurate (confidence 2)  [6CEF18F6], AccurateRip returned [41EFB4BF]
Track  3  cannot be verified as accurate (confidence 2)  [F1FD619B], AccurateRip returned [1EC8B4A5]
Track  4  cannot be verified as accurate (confidence 2)  [49F2315B], AccurateRip returned [FB9B2DF2]
Track  5  cannot be verified as accurate (confidence 2)  [866E0C80], AccurateRip returned [590B95DF]
Track  6  cannot be verified as accurate (confidence 2)  [93F11EC8], AccurateRip returned [919F7895]
Track  7  cannot be verified as accurate (confidence 2)  [6148B71D], AccurateRip returned [52AB16FB]
Track  8  cannot be verified as accurate (confidence 2)  [6963ADF9], AccurateRip returned [522BED4E]
Track  9  cannot be verified as accurate (confidence 2)  [5F2E26E3], AccurateRip returned [0C3A1EA5]

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-25 15:18:07
Your rip matched the entry in the CTDB so confidence there is now 2 and your rip is accurate according to that database. I'm getting this info from the database using info in the log, not from the log itself. Sorry, I should have been more specific on the logs. I meant *.log and *.accurip for the last rip only. The *.accurip log gives additional info.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-03-25 16:42:19
Can either CueRipper or CueTools be used in single file mode, or do I have to do all operations on all tracks always?

I'm quickly jumping into the CueTools bandwagon after years of using EAC.  I ripped one of my old CD's (in great shape) and after many tries, finally got an error-free rip (according to EAC) of two tracks that would not verify in the AR database.  Then I listened to those two tracks and found audible glitches on both of them.  This sent brought my confidence in EAC very low.  Today I tried CueRipper on the same CD, although a different drive, and only one of the problem tracks would not verify but it sounded glitch free, all of this on the first attempt!  I then proceeded to repair it with CueTools and it managed to verify afterwards.

What does CueTools actually repair?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eleria on 2013-03-25 16:42:44
@korth Ah, I'm relieved. Thanks for the quick replies :3
I'm a bit new to CueTools it's only been like 6 rips, so of course I didn't check what's in the accurip
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-25 18:21:23
Can either CueRipper or CueTools be used in single file mode, or do I have to do all operations on all tracks always?
Assuming you meant single track. CUERipper can only rip entire discs. It cannot rip just one or two tracks. CUETools is also designed to work on the entire disc rip, not just one or two tracks.
Quote
What does CueTools actually repair?
The CTDB stores a very small recovery record similar to PAR2 (http://wiki.hydrogenaudio.org/index.php?title=Par2). See also CUETools_Database (http://www.cuetools.net/wiki/CUETools_Database). (Some of the text isn't up to date but the general idea is the same. I'll update it this week.)

I'm a bit new to CueTools it's only been like 6 rips, so of course I didn't check what's in the accurip
Don't forget to look over the wiki pages (http://www.cuetools.net/wiki/Main_Page).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-03-25 18:32:12
Assuming you meant single track. CUERipper can only rip entire discs. It cannot rip just one or two tracks. CUETools is also designed to work on the entire disc rip, not just one or two tracks.


I see.  Thanks for your answers.  The reason I asked about single track ripping is because with EAC, sometimes I could not get a track or two to verify with the first attempt but a second ripping attempt would get it right.  This would happen because I would change the ripping mode, or simply a second shot at the same ripping mode. It was a painful iterative process with some tracks on some CD’s, but it would have been worst if I had to re-rip the entire disc on each attempt.

Is this not necessary with CueRipper?
If I can’t get a track to verify the first time, no amount of retries will do it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-25 18:41:39
You can change the extraction method but you have to re-rip the entire disc. See Extraction method (http://www.cuetools.net/wiki/CUERipper_Settings#.2818.29_Extraction_method_.7Bslider.7D). On scuffed or scratched discs, I use Paranoid.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-03-25 18:57:50
Thanks.  I'll keep playing with CueRipper to understand its capabilities, but I like it already.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lazlo Nibble on 2013-03-25 21:33:27
Is there (or will there soon be) a way to get ArCueDotNet.exe to output the full "detailed" log with the CTDB information?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-03-25 22:30:11
Is there (or will there soon be) a way to get ArCueDotNet.exe to output the full "detailed" log with the CTDB information?

[attachment=7445:ArCueDotNet.exe.zip]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-03-26 01:04:24
Is there any way I can add album artists as a tag when ripping with CueRipper?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-03-26 01:45:52
It is supposed to just work. I mean, if you specify track artists different from album artist.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-03-26 02:59:24
It is supposed to just work. I mean, if you specify track artists different from album artist.

Sorry for the silly question.  I was about to retract it because I just ripped an album that had songs from more than one artist and it showed up.
I'm really liking your apps!

Thanks for your support.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-29 21:41:31
Hmm something I noticed: when verifying albums with CUETools, it looks at both AR and CTDB and reports the result. However when encoding it only checks AR.
Is there an option I'm missing or is it intended?

edit: also, I can't seem to find where I can disable caching. For some reason, even though I already changed the tags with foobar CUETools keeps insisting on writing the old version of tags upon conversion, despite multiple restarts, reopening the folders etc...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-29 22:01:04
Quote
Is there an option I'm missing or is it intended?
This is normal behavior. There is no 'Use CTDB' checkbox under 'Mode' on the GUI when 'Encode' is selected under 'Action'.
Quote
also, I can't seem to find where I can disable caching.
http://www.cuetools.net/wiki/CUETools_Adva...tings:_Advanced (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced)
Quote
For some reason, even though I already changed the tags with foobar CUETools keeps insisting on writing the old version of tags upon conversion, despite multiple restarts, reopening the folders etc...
Are the old tags still in the CUE file?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-29 22:05:52
You're right. Though it's kinda a bummer, now I will have to re-verify my whole library after converting it to single tracks :|
One more thing, the "copy albumart tags" option ignores any covers in .png format...

edit: I was about to post that I don't have a "cache" option there when I noticed the scroll bar was not in the topmost position. It was aligned perfectly so that the list started at "Cover Art". And the weird thing is, when I adjust the scroll bar, close the dialog and reopen it, it returns to starting at "Cover Art". And it also only happens when you have the "Cover Art" section expanded. No wonder I couldn't find it lol

edit2: no, both .cue and the files had the same tags. In the end I ended up renaming the folder the files were in temporarily and it saw the new tags.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-29 22:31:32
Quote
One more thing, the "copy albumart tags" option ignores any covers in .png format...
When I tested 'Cover Art Files', jpeg, png, gif and bmp didn't appear to work (only jpg). I already reported this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-30 14:51:37
Is there a way to tell CUETools to look for audio files corresponding to a .cue in a different folder? I think this could be possible by creating a custom script, but I couldn't find any reference which variables can be used etc. Something like SetWorkdir="..\" maybe?

In my case, I have the following structure:

album\files\album.cue
album\track 01.flac
...

I apologize if it was asked already, but I can't seem to be able to find anything. Would it be possible to additionally filter by .cue, so that when I select my whole music library, only the .cue files will be used to transcode, not the separate tracks? Thanks in advance.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-30 19:01:11
I'll defer on the first part.
Quote
In my case, I have the following structure:[blockquote]album\files\album.cue
album\track 01.flac[/blockquote]
AFAIK, CUETools expects the CUE and EAC LOG to be in the same folder as the audio files. However, if you set the full path for each audio file in the CUE file, CUETools can process that CUE file from another folder (and EAC LOG if in same folder as CUE).
[blockquote]FILE "c:\mymusicfiles\album\track 01.flac" WAVE[/blockquote]
Quote
so that when I select my whole music library, only the .cue files will be used to transcode, not the separate tracks?
You can select to use only the CUE files during batch encoding.
Hint#1: Windows Search c:\mymusicfiles and subfolders for *.cue. Highlight the ones you want to use from the results. Drag them into 'Drag'n'drop mode' window.
Hint#2: Use 'Multiselect Browser mode'. Expand mymusicfiles and desired subfolders. Check the boxes next to the desired CUE files.

(naturally 'c:\mymusicfiles' is only an example of any folder containing music files.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-03-31 16:13:54
I noticed two possible bugs with CueRipper:

1. It does not remember choice of output format (always goes back to flac, when restarting the program)
2. Album art is always embedded on rips, even when de-selecting the option to do so

I've noticed the above when ripping to ALAC format.

Best Regards.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-03-31 16:21:03
Must be something on your end. Mine saves the format fine, didn't try to disable album art embedding, but I think that might be related to CUETools seemingly not saving your settings. If you don't have user profiles enabled, it probably tries to write to C:\, which would fail if it doesn't request administrative privileges. This is assuming you're on win vista or later with UAC enabled.

@Korth: thanks, filtering by .cue in explorer sounds like a good idea. Ticking everything in browser mode isn't so convenient when converting the whole library with ~200 folders.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-03-31 18:22:57
themanuel,
CUERipper settings file location: %appdata%/CUERipper/settings.txt (Windows Key + r will open run box if you want to view the file).
CUERipper needs to write to this file on exit to save any changes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-04-02 02:16:15
themanuel,
CUERipper settings file location: %appdata%/CUERipper/settings.txt (Windows Key + r will open run box if you want to view the file).
CUERipper needs to write to this file on exit to save any changes.


Thanks, but I may have a different problem.  Other settings seem to save fine.  When I open the settings file it does show the embed album art parameter with a value of 0 but the resulting alac files still have the art embedded within.  Unless either Windows 7 or iTunes is embedding the image from folder.jpg on each track file.

If that's the case, I'll still be scratching my head as to why the format defaults to flac when I restart CueRipper.  I don't really see this option in the settings file, but it happens to be the first option in the drop-down menu and maybe that's why it always start there.  It's no big deal but sometimes I forget to set it back to .m4a when I restart CueRipper and start ripping into flac instead of .m4a.

If somebody can point me to this parameter in the settings file, that would be great.

Thanks again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-02 04:08:50
Sorry, I finally had a chance to test these and can confirm both problems. The other setting you were looking for is 'DefaultLosslessFormat=' but it doesn't matter.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: themanuel on 2013-04-02 21:59:53
Sorry, I finally had a chance to test these and can confirm both problems. The other setting you were looking for is 'DefaultLosslessFormat=' but it doesn't matter.

Thanks for confirming that.
I do have DefaultLosslessFormat set to .m4a but as you found out, CueRipper still defaults to .flac container when starting up.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-03 21:29:35
CUETools complains about 2 "albums", one is a digital only release with a sample rate of 48khz, another one is a game rip with a sample rate of 22,5khz. In both cases it says the format is invalid... Files decode fine in foobar though, I assume CUETools only handles 44,1kHz files?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-03 22:30:16
Yes, 16-bit 44.1 kHz Stereo CD-DA (http://wiki.hydrogenaudio.org/index.php?title=Compact_Disc_Digital_Audio) (Red Book) for input.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-04-11 01:22:21
CUERipper's handling of AccurateRip and CTDB submissions still mystifies me. Today while experimenting with burst mode, I got "AR: rip accurate (44/44), CTDB: disk not present in database, insufficient quality."

Code: [Select]
[CUETools log; Date: 4/10/2013 6:00:37 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: 0Z0vBojTm3ENuDvKLGSe4daWlEw-] disk not present in database.
[AccurateRip ID: 000ba559-003d9dd0-520b1806] found.
Track  [  CRC  |  V2  ] Status
 01    [d94b89c4|f2c2d959] (42+04/46) Accurately ripped
 02    [151fcaf7|54e460d5] (42+04/46) Accurately ripped
 03    [ea4f7df1|e944873a] (41+04/45) Accurately ripped
 04    [e419b7f9|6df12198] (42+04/46) Accurately ripped
 05    [5d270e84|cc7fc6d4] (42+04/46) Accurately ripped
 06    [9e561a14|f49c1ff0] (40+04/44) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [EDC7DA6E] [899889DB]         
 01  99.4 [E61B076B] [CF1AF1EB]         
 02  99.7 [510F5D70] [932D687A]         
 03  100.0 [D05202B6] [9739E9A7]         
 04  99.2 [7181379B] [01F7F213]         
 05  99.9 [71C4A87B] [5423EDA5]         
 06  99.6 [C0C9DC68] [8AC2AAE9]         

Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 10. April 2013, 18:00

Orchestra Baobab / Pirates Choice

Used drive  : PLDS DVD-RW DH16ABSH  Adapter: 1  ID: 0

Read mode              : Burst
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.32 |  8:43.33 |        32    |    39289 
        2  |  8:43.65 |  7:45.30 |    39290    |    74194 
        3  | 16:29.20 |  8:58.57 |    74195    |  114601 
        4  | 25:28.02 |  6:48.15 |    114602    |  145216 
        5  | 32:16.17 |  7:01.25 |    145217    |  176816 
        6  | 39:17.42 |  8:03.30 |    176817    |  213071 


Track  1

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[01] Orchestra Baobab - Utrus Horas.wav

    Pre-gap length  0:00:02.42

    Peak level 99.4 %
    Track quality 100.0 %
    Copy CRC E61B076B
    Accurately ripped (confidence 46)  [D94B89C4]
    Copy OK

Track  2

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[02] Orchestra Baobab - Coumba.wav

    Pre-gap length  0:00:03.73

    Peak level 99.7 %
    Track quality 100.0 %
    Copy CRC 510F5D70
    Accurately ripped (confidence 46)  [151FCAF7]
    Copy OK

Track  3

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[03] Orchestra Baobab - Ledi Ndieme M'bodj.wav

    Pre-gap length  0:00:02.84

    Peak level 100.0 %
    Track quality 100.0 %
    Copy CRC D05202B6
    Accurately ripped (confidence 45)  [EA4F7DF1]
    Copy OK

Track  4

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[04] Orchestra Baobab - Werente Serigne.wav

    Pre-gap length  0:00:04.42

    Peak level 99.2 %
    Track quality 100.0 %
    Copy CRC 7181379B
    Accurately ripped (confidence 46)  [E419B7F9]
    Copy OK

Track  5

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[05] Orchestra Baobab - Ray M'bele.wav

    Pre-gap length  0:00:03.73

    Peak level 99.9 %
    Track quality 100.0 %
    Copy CRC 71C4A87B
    Accurately ripped (confidence 46)  [5D270E84]
    Copy OK

Track  6

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[06] Orchestra Baobab - Soldadi.wav

    Pre-gap length  0:00:03.73

    Peak level 99.6 %
    Track quality 100.0 %
    Copy CRC C0C9DC68
    Accurately ripped (confidence 44)  [9E561A14]
    Copy OK


All tracks accurately ripped

No errors occurred

End of status report

Why "insufficient quality" for this?

So then I re-ripped in Secure mode, and sure enough, it was acceptable: "AR: rip accurate (44/44), CTDB: disk not present in database, 0Z0vBojTm3ENuDvKLGSe4daWlEw- has been uploaded."

Code: [Select]
[CUETools log; Date: 4/10/2013 6:10:17 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: 0Z0vBojTm3ENuDvKLGSe4daWlEw-] disk not present in database.
CUETools DB: insufficient quality.
[AccurateRip ID: 000ba559-003d9dd0-520b1806] found.
Track  [  CRC  |  V2  ] Status
 01    [d94b89c4|f2c2d959] (42+04/46) Accurately ripped
 02    [151fcaf7|54e460d5] (42+04/46) Accurately ripped
 03    [ea4f7df1|e944873a] (41+04/45) Accurately ripped
 04    [e419b7f9|6df12198] (42+04/46) Accurately ripped
 05    [5d270e84|cc7fc6d4] (42+04/46) Accurately ripped
 06    [9e561a14|f49c1ff0] (40+04/44) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [EDC7DA6E] [899889DB]         
 01  99.4 [E61B076B] [CF1AF1EB]         
 02  99.7 [510F5D70] [932D687A]         
 03  100.0 [D05202B6] [9739E9A7]         
 04  99.2 [7181379B] [01F7F213]         
 05  99.9 [71C4A87B] [5423EDA5]         
 06  99.6 [C0C9DC68] [8AC2AAE9]         

Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 10. April 2013, 18:00

Orchestra Baobab / Pirates Choice

Used drive  : PLDS DVD-RW DH16ABSH  Adapter: 1  ID: 0

Read mode              : Burst
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.32 |  8:43.33 |        32    |    39289 
        2  |  8:43.65 |  7:45.30 |    39290    |    74194 
        3  | 16:29.20 |  8:58.57 |    74195    |  114601 
        4  | 25:28.02 |  6:48.15 |    114602    |  145216 
        5  | 32:16.17 |  7:01.25 |    145217    |  176816 
        6  | 39:17.42 |  8:03.30 |    176817    |  213071 


Track  1

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[01] Orchestra Baobab - Utrus Horas.wav

    Pre-gap length  0:00:02.42

    Peak level 99.4 %
    Track quality 100.0 %
    Copy CRC E61B076B
    Accurately ripped (confidence 46)  [D94B89C4]
    Copy OK

Track  2

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[02] Orchestra Baobab - Coumba.wav

    Pre-gap length  0:00:03.73

    Peak level 99.7 %
    Track quality 100.0 %
    Copy CRC 510F5D70
    Accurately ripped (confidence 46)  [151FCAF7]
    Copy OK

Track  3

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[03] Orchestra Baobab - Ledi Ndieme M'bodj.wav

    Pre-gap length  0:00:02.84

    Peak level 100.0 %
    Track quality 100.0 %
    Copy CRC D05202B6
    Accurately ripped (confidence 45)  [EA4F7DF1]
    Copy OK

Track  4

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[04] Orchestra Baobab - Werente Serigne.wav

    Pre-gap length  0:00:04.42

    Peak level 99.2 %
    Track quality 100.0 %
    Copy CRC 7181379B
    Accurately ripped (confidence 46)  [E419B7F9]
    Copy OK

Track  5

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[05] Orchestra Baobab - Ray M'bele.wav

    Pre-gap length  0:00:03.73

    Peak level 99.9 %
    Track quality 100.0 %
    Copy CRC 71C4A87B
    Accurately ripped (confidence 46)  [5D270E84]
    Copy OK

Track  6

    Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[06] Orchestra Baobab - Soldadi.wav

    Pre-gap length  0:00:03.73

    Peak level 99.6 %
    Track quality 100.0 %
    Copy CRC C0C9DC68
    Accurately ripped (confidence 44)  [9E561A14]
    Copy OK


All tracks accurately ripped

No errors occurred

End of status report

Why wasn't the burst rip acceptable? It was no better or worse than the secure rip; the output was identical.

And why does the secure rip's .accurip log say "insufficient quality"?! Shouldn't it be the other way around?

Is it unreasonable for me to expect things to make more sense than this? Would it help to enable the detailed log?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-11 04:06:35
Burst rips are not acceptable (insufficient quality) for CTDB, because if your drive doesn't return C2 errors reliably, there can be any amount of undetected errors in burst mode.
You only know that the rip was actually good because it matched AccurateRip database (on which CTDB no longer relies for various philosophical reasons), and because it matched your second rip (to which it couldn't compare it because it was not yet made and time travel is not yet invented).

Somehow .accurip files have mixed up it seems; The result from the first rip crept up into the second log. I will need to look into that.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-11 04:07:28
Did you post the same rip log twice? Both say "extraction logfile from 10. April 2013, 18:00". If not, there is a bug in CUERipper where some of the log data isn't cleared if you rip the same disc a second time without reloading the disc. [Reminder of bug to Gregory]

'Burst' mode is one pass (if no C2) and one pass is insufficient quality to submit when no previous records of that disc exist in the CTDB (AccurateRip data is ignored). I think if you had enabled 'Test and Copy' and both CRCs matched then the quality would be sufficient to submit a new disc record (but Gregory would need to confirm this). 'Secure' mode is a minimum of two passes so the CRCs were double checked and the quality was sufficient to submit a new disc.

Edit: [Gregory beat me to it]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-04-11 06:20:12
Thanks for the responses.

The .log files are indeed identical; I didn't post the same one twice (well, I suppose it depends on how you look at it ). In between rips, I renamed the output folder, so it's not a case of an existing file being in the way.

The .accurip files are also identical, except for the date/time and "CUETools DB: insufficient quality." appearing erroneously in the secure rip rather than the burst rip.

How does CUERipper determine whether to make use of C2 pointers?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-11 12:37:38
Speaking of logs, why are there sometimes entries like:
accurate rip id xxxx found

track1 0+0/0, rip not accurate
...

Can't post the actual log because I can't find the disc which had it atm =|
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-11 13:51:30
ChronoSphere,
See [a href='index.php?act=findpost&pid=743235']this post[/a]
Quote from: Goratrix link=msg=0 date=
Do I interpret it correctly, that between November and today, there has been a new submission for this disc, with different data than the previous one, and therefore both of them have been moved to "limbo"? But the disc ID itself stays in the database, so we get this weird 0/0 result?

and this dbpoweramp thread (http://forum.dbpoweramp.com/archive/index.php?t-20464.html).
Quote from: spoon link=msg=0 date=
A guy rips a disc and gets an incorrect rip as [BBBBBBB] (because of scratch), it submits and this result is in the db. You rip correctly get [AAAAAAAA], submit, now neither results are in the db, 3rd guy rips and submits [AAAAAAAA], now only [AAAAAAAA] appears.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: FulciLives on 2013-04-13 10:33:21
I'm really trying hard to switch full time to Linux but I find myself using this program a lot (I have Windows 7 in VirtualBox).

I know I know you probably have heard it before but here is another vote for making a native Linux version, or at least a version that works in Linux under WINE etc.

I did read somewhere people have run it with under Linux with MONO but I haven't tried since it only supports WAV and then I assume there is no tagging and that just doesn't sound like a great solution.

Sorry if you find this request an annoying one (like I said I'm sure you've heard it before) but Linux is finally catching on now in a big way and with STEAM now on Linux it will just be getting more and more popular so please consider it.

Thank you!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-15 03:19:31
I know I know you probably have heard it before but here is another vote for making a native Linux version, or at least a version that works in Linux under WINE etc.

I did read somewhere people have run it with under Linux with MONO but I haven't tried since it only supports WAV and then I assume there is no tagging and that just doesn't sound like a great solution.

It doesn't get a lot of testing, but it should work with MONO, and work almost as good as native applications. Theoretically you can even build a static Linux binary from it using mkbundle from mono-devel. It will compile it to a native application more or less.

And the bit about it only supporting WAV is probably outdated. There are managed FLAC and ALAC codecs in cuetools. If it doesn't work for some reason, it probably doesn't take much work to fix it. It's just a matter of finding time for it, or finding someone willing to find some time
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: unfinished.hide on 2013-04-15 06:13:57
I'm currently on linux as well (Linux Mint 14) and the best way around I've found to use CUETools has been with wine + the required .Net libraries installed through the command winetricks. Everything I tested works great so far (transcoding to flac from different formats using libflake, verifying with Accuraterip/CTDB, HDCD decoding) and the only small issue was to set wine envirorment to work as 32bit in my x64 computer or .Net installer would refuse to run.

I also tested CUETools with mono, but the experience wasn't that good. Wine + mono for windows had a very annoying issue. CUETools seemed to work fine, but the progress bar at the botton just disappears with all the info regarding AccurateRip and CTDB, whereas with Mono for linux (no wine needed), the GUI was completely screwed. Could never find the Go button to run it, plus only WAV decoding still applied as it was the only encoder available.

Would love to see a native version for linux though (and CUERipper too!)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ManekiNeko on 2013-04-15 18:23:57
Any idea the correct setup to add fhgaacenc?

I've copied the required files into Cuetools directory and added this:

Path: fhgaacenc.exe
Parameters: --vbr %M - -o %O
Modes: 1 2 3 4 5 6

But it's not working

Error: "fhgaacenc.exe has exited prematurely with code 0: The pipe has been ended."

It seems my parameters are wrong

EDIT: Parameters: --vbr %M - %O  works fine
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2013-04-15 18:53:06
In addition to the features requested, if any, please make the next version completely portable with the option to save the configuration folder inside the app folder. Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-15 19:18:38
Deleting the user_profiles_enabled file makes it portable and saves config file in the app folder in subfolder(s) \CUE Tools for CUETools and \CUERipper for CUERipper. You can copy the files from the %appdata% locations to save all your settings and profiles.

(of course .NET Framework 2.0 SP2 and Visual C++ 2008 runtime files are needed on each computer)

Edit: additional info
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2013-04-15 19:21:05
Deleting the user_profiles_enabled file makes it portable and saves config file in the app folder.

Perfect, thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-17 13:14:11
Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.
I can confirm this error.
Any update on this one? My drive is a HL-DT-ST - DVD-RAM GH22NS30 if that's of any relevance. Same as Pepzhez, ticking Test&Copy leads to "gap detection failed" error.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-17 13:18:13
I will try not to forget to fix this
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-17 14:29:41
I will try not to forget to fix this

Thanks, looking forward to it. Have to revert to EAC in the meantime, since failing gap detection results in .cue only having INDEX001 with entries of 0:00:00 for all tracks...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-17 15:53:03
This bug just goes to show that i don't really understand why people want Test&Copy, that is why i didn't test it much. Secure mode is faster and safer than Test & Copy Burst mode, and Paranoid mode is faster and safer than Test & Copy Secure mode. The only reason i have Test&Copy mode at all is that people got used to this strange feature in EAC, where it made at least some kind of sense.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-17 16:29:15
I thought those two are related. But it seems it's something different. When I rip in image mode, it produces a cuesheet like this (compliant)
Code: [Select]
REM ACCURATERIPID 000373d1-000def36-3704e104
REM DISCID 3704E104
PERFORMER "fripSide"
TITLE "only my railgun"
CATALOG 4988102620523
REM DATE 2009
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov"
FILE "fripSide - only my railgun.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "fripSide"
    TITLE "only my railgun"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PERFORMER "fripSide"
    TITLE "late in autumn"
    INDEX 01 04:17:07
  TRACK 03 AUDIO
    PERFORMER "fripSide"
    TITLE "only my railgun -instrumental-"
    INDEX 01 10:26:39
  TRACK 04 AUDIO
    PERFORMER "fripSide"
    TITLE "late in autumn -instrumental-"
    INDEX 01 14:43:31

However, in single tracks mode, it produces a cuesheet that looks like this (all start times are zero)
Code: [Select]
REM ACCURATERIPID 000373d1-000def36-3704e104
REM DISCID 3704E104
PERFORMER "fripSide"
TITLE "only my railgun"
CATALOG 4988102620523
REM DATE 2009
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov"
FILE "01. fripSide - only my railgun.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "fripSide"
    TITLE "only my railgun"
    INDEX 01 00:00:00
FILE "02. fripSide - late in autumn.flac" WAVE
  TRACK 02 AUDIO
    PERFORMER "fripSide"
    TITLE "late in autumn"
    INDEX 01 00:00:00
FILE "03. fripSide - only my railgun -instrumental-.flac" WAVE
  TRACK 03 AUDIO
    PERFORMER "fripSide"
    TITLE "only my railgun -instrumental-"
    INDEX 01 00:00:00
FILE "04. fripSide - late in autumn -instrumental-.flac" WAVE
  TRACK 04 AUDIO
    PERFORMER "fripSide"
    TITLE "late in autumn -instrumental-"
    INDEX 01 00:00:00

I expected it to look like this
Code: [Select]
REM DATE 2009
REM DISCID 3704E104
REM COMMENT "ExactAudioCopy v1.0b3"
CATALOG 4988102347550
PERFORMER "fripSide"
TITLE "only my railgun"
FILE "01. fripSide - Only my railgun.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Only my railgun"
    PERFORMER "fripSide"
    ISRC JPPI00963400
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Late in autumn"
    PERFORMER "fripSide"
    ISRC JPPI00963680
    INDEX 00 04:11:38
FILE "02. fripSide - Late in autumn.flac" WAVE
    INDEX 01 00:00:00
  TRACK 03 AUDIO
    TITLE "Only my railgun ~Instrumental~"
    PERFORMER "fripSide"
    ISRC JPPI00963409
    INDEX 00 06:05:64
FILE "03. fripSide - Only my railgun ~Instrumental~.flac" WAVE
    INDEX 01 00:00:00
  TRACK 04 AUDIO
    TITLE "Late in autumn ~Instrumental~"
    PERFORMER "fripSide"
    ISRC JPPI00963689
    INDEX 00 04:11:24
FILE "04. fripSide - Late in autumn ~Instrumental~.flac" WAVE
    INDEX 01 00:00:00

Also, there seems to be a difference in times between EAC image+cue and CUERipper image+cue, both offsets are set to 102 as per AccurateRip/CUERipper's auto detection. I think I am misunderstanding something here...

edit: I... probably should stop worrying about the different .cue formats and why some programs use the INDEX00/01 entries or both. It probably depends on gap settings or something, the result of burning these different .cue should be identical in the end, is that correct?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-17 17:21:10
INDEX 01 00:00:00 is the normal track start position in per-track (multiple file) cue sheets. See http://wiki.hydrogenaudio.org/index.php?title=Cue_sheet (http://wiki.hydrogenaudio.org/index.php?title=Cue_sheet)
Gaps weren't detected in the first two cue sheets. Check the rip logs.
Probably says
Gap handling  : Not detected, thus appended to previous track
instead of
Gap handling  : Appended to previous track
The INDEX 00 references in the third cue sheet are the start positions of the gaps.
Quote
Also, there seems to be a difference in times between EAC image+cue and CUERipper image+cue
difference in times? Are you referring to gaps?  CUERipper may detect gaps a little different than EAC so the INDEX 00 references may differ slightly.

(I'm assuming all rips are gaps appended)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-17 18:08:55
If it's saying "Gap handling: Not detected, thus appended to previous track", does that mean "not detected for this CD" / "it doesn't have gaps" or does that mean CUERipper can't detect the gaps with my drive?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2013-04-17 18:43:52
Any idea the correct setup to add fhgaacenc?

I've copied the required files into Cuetools directory and added this:

Path: fhgaacenc.exe
Parameters: --vbr %M - -o %O
Modes: 1 2 3 4 5 6

But it's not working

Error: "fhgaacenc.exe has exited prematurely with code 0: The pipe has been ended."

It seems my parameters are wrong

EDIT: Parameters: --vbr %M - %O  works fine

I would like to know this as well, I've tested few different commands but I couldn't find the right one.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-17 18:58:11
If it's saying "Gap handling: Not detected, thus appended to previous track", does that mean "not detected for this CD" / "it doesn't have gaps" or does that mean CUERipper can't detect the gaps with my drive?

Note: I should've mentioned in the previous reply that 'Gap handling: Not detected, thus appended to previous track' only appears in the log of per-track (multiple file) rips.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-17 19:07:32
I would like to know this as well, I've tested few different commands but I couldn't find the right one.

I haven't tested (because I don't have the required winamp dll files) but this should work:
Path: fhgaacenc.exe
Parameters: --vbr %M - %O
Modes: 1 2 3 4 5 6

provided the following are in the same location as the fhgaacenc.exe:
libsndfile-1.dll
enc_fhgaac.dll
libmp4v2.dll
nsutil.dll
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ManekiNeko on 2013-04-17 19:23:16
I would like to know this as well, I've tested few different commands but I couldn't find the right one.

I haven't tested (because I don't have the required winamp dll files) but this should work:
Path: fhgaacenc.exe
Parameters: --vbr %M - %O
Modes: 1 2 3 4 5 6

provided the following are in the same location as the fhgaacenc.exe:
libsndfile-1.dll
enc_fhgaac.dll
libmp4v2.dll
nsutil.dll


Yes, it does work. I added the 'edit' to my post after working it out 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vivadavid on 2013-04-18 16:28:59
Hello everybody,

I don't know if this is the best place to explain my problem, but I'm following a link from the CUETools Wiki. I'm trying to split into tracks a CUE file pointing to an MP3 file, but it says "unsupported audio type". I've converted the MP3 file into FLAC, I've edited the CUE file to point to this FLAC file and CUETools does allow me to split it into the different tracks, so it seems that definitely the problem has to do with the MP3 codec. I've checked it out and the mp3 DLL files are in the plugins folders. I forgot to say that I'm using the portable version of CUETools 2.1.4.

Thank you very much for your help

David
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-18 16:34:22
CUETools does not support mp3 input files, because mp3 is a lossy codec, and because decoding lossy audio and re-encoding it again degrades sound quality.

There are programs that can cut mp3 files without re-encoding them, see http://www.hydrogenaudio.org/forums/index....showtopic=71172 (http://www.hydrogenaudio.org/forums/index.php?showtopic=71172)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2013-04-18 17:01:01
I didn't see the edit line, it works perfectly thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vivadavid on 2013-04-18 17:12:44
Thank you, Gregory. I've tried it, and mp3directcut works well for me.

However, I can't understand why CUETools offers MP3 as an option and why there are MP3 codecs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-18 17:44:43
Because you can convert from any lossless format to mp3 using CUETools. This is not the main purpose of CUETools, but that feature was easy to implement and is often used.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vivadavid on 2013-04-18 18:19:57
I see! Thanks again, Gregory!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: antigeek on 2013-04-23 18:10:01
no one discussing the new v2.1.5 beta/tryout version?

http://www.cuetools.net/wiki/CUETools_Download (http://www.cuetools.net/wiki/CUETools_Download)
http://www.cuetools.net/wiki/CUETools_Changelog (http://www.cuetools.net/wiki/CUETools_Changelog)

bug tracker already mentions v2.1.6
http://sourceforge.net/p/cuetoolsnet/bugs/ (http://sourceforge.net/p/cuetoolsnet/bugs/)

cueripper:
i still have a lot of system crash/hangs during 'detecting drive features', with any of my 4 drives (2x plextor, liteon, lg), i hope this will be resolved one day.
so the old problem with any rip-mode except 'secure' does make the whole system hang, persists.
new:  secure with test&copy sometimes does 31 re-reads, sometimes only 1 - without test&copy always 1 re-read - still better than v2.1.4 where test&copy always crashes.

i'd like to help the author to find out what makes system crash, something in bwg.scsi i guess...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-23 18:17:05
You have the same problems with every drive? I would appreciate a more detailed report - including OS version, hardware, etc. Anything unusual about your system? How exactly does the crash look like?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: antigeek on 2013-04-23 18:37:33
You have the same problems with every drive? I would appreciate a more detailed report - including OS version, hardware, etc. Anything unusual about your system? How exactly does the crash look like?


Ok.
Win7 X64 Professional, German
Cuetools v2.1.4 and v2.1.5 both english
Drives: Plextor 755a, Plextor Premium, LiteOn 48125W, LG 4165B (all IDE)
EDIT: you'd call that ancient hardware but they all work very good

EAC, Foobar2000, Plextools Pro/LE rippers always work.

'Crash' is a total system freeze, no mousepointer movement, no keyboard, disc interaction etc.
Happens always during 'detecting drive features' except when in 'secure' mode.

When aborting a running rip, and hitting 'go' again with the disc still spinning also crashes, with the exact same settings that worked seconds before.

I read someone reported this here in 2011 and waited for more than 10 minutes and system came back with a dead drive, i never had this 'comeback' yet.

any more infos?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-23 19:39:11
  • The CD may have no detectable gaps
  • CUERipper can't detect the gaps on that drive
  • The option (http://www.cuetools.net/wiki/CUERipper_Options#Extraction) is disabled in CUERipper
Note: I should've mentioned in the previous reply that 'Gap handling: Not detected, thus appended to previous track' only appears in the log of per-track (multiple file) rips.
The options "preserve HTOA" and "detect indices" are set to "true" and the HTOA is extracted as Track 00 on CDs that have it, but gaps still report as "not detected". Do you have any suggestions how to test if it's the drive? I tried all drives we have in our household with a few CDs and all of them give that message. I'm just worried about burning those back to the CD since I'm ripping it to lossless mostly as a backup.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: antigeek on 2013-04-23 22:35:40
update: drives connected via usb-ide adapter (http://www.sharkoon.com/?q=en/content/quickport-combo) work surprisingly well
in all rip modes (burst,secure,paranoid with test&copy on and off) with v2.1.5,
even when the disc is still spinning from aborted rip.
so maybe my onboard ide controller (asrock 890fx deluxe5) is not very compatible with your 'detect drive features' algorithm ?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2013-04-23 23:49:47
Hi Gregory. I think i asked once but now that you are on the new version is there a chance to disable writing the COMMENT field from the cue to tag? One more option for that undere Advanced-Tagging really would be nice
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-23 23:54:07
If possible, I'd like to request that "always write utf-8 .cuesheet" option for this new version, thank you
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-24 04:58:05
edit: I... probably should stop worrying about the different .cue formats and why some programs use the INDEX00/01 entries or both. It probably depends on gap settings or something, the result of burning these different .cue should be identical in the end, is that correct?
I'm just worried about burning those back to the CD since I'm ripping it to lossless mostly as a backup.
I personally don't worry too much about gaps. If gaps are 'Appended to previous track' or are 'Not detected, thus appended to previous track', the resulting audio files are the same. See the 'Writing gaps' section in this hydrogenaudio wiki tutorial written about EAC Gap Settings (http://wiki.hydrogenaudio.org/index.php?title=EAC_Gap_Settings).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-24 14:44:59
Understood, thank you korth.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ThePampers on 2013-04-24 19:31:25
A special thanks to Gregory for the new (incoming) version  ...
One question : how can i change the 'totaltrack' & 'totaldisc' tags with the reference standard 'tracktotal' & 'disktotal' during the flac creation ?
'Albumartist' tag is supported ? In the setting file i don't see anything...
Any chance in future to see the option 'capitalize first letter' in the tags option ?
Thanks in advance .
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: whysoserious on 2013-04-25 17:42:07
Code: [Select]
[CUETools log; Date: 25.4.2013 г. 19:19:09; Version: 2.1.4]
[CTDB TOCID: 3z8odFV3jnWsbEMRXrW9FU_BQF8-] found.
Track | CTDB Status
  1  | (474/486) Accurately ripped
  2  | (475/486) Accurately ripped
  3  | (478/486) Accurately ripped
  4  | (477/486) Accurately ripped
  5  | (476/486) Accurately ripped
  6  | (476/486) Accurately ripped
  7  | (479/486) Accurately ripped
  8  | (474/486) Accurately ripped
  9  | (475/486) Accurately ripped
 10  | (467/486) Accurately ripped
[AccurateRip ID: 000ef298-0078238f-8909cc0a] found.
Track  [  CRC  |  V2  ] Status
 01 [2035f107|e17eac17] (200+114/1064) Accurately ripped
 02 [3e6b300b|8f4345fa] (200+113/1058) Accurately ripped
 03 [8d36f4f8|afd25f29] (200+114/1062) Accurately ripped
 04 [89cacf08|98934068] (200+114/1064) Accurately ripped
 05 [e7080942|6605142a] (200+113/1066) Accurately ripped
 06 [17f24b51|66cf23bf] (200+112/1064) Accurately ripped
 07 [1b566b73|76094fdd] (200+114/1066) Accurately ripped
 08 [639da5fc|65d0ccd5] (200+113/1059) Accurately ripped
 09 [8b75923c|23435bc4] (200+114/1061) Accurately ripped
 10 [aa5757c8|91745db1] (200+111/1061) Accurately ripped
[color=#FF0000]Offsetted by -2116[/color]:
 01 [dcdf0a75] (011/1064) Accurately ripped
 02 [86ac18b5] (011/1058) Accurately ripped
 03 [cfcedf54] (011/1062) Accurately ripped
 04 [df9f6e94] (011/1064) Accurately ripped
 05 [2f02a3bf] (011/1066) Accurately ripped
 06 [76d1fbbc] (011/1064) Accurately ripped
 07 [81c48137] (011/1066) Accurately ripped
 08 [012755bc] (011/1059) Accurately ripped
 09 [8c861a66] (011/1061) Accurately ripped
 10 [2a742822] (012/1061) Accurately ripped
[color=#FF0000]Offsetted by -2080[/color]:
 01 [29a71a5d] (099/1064) Accurately ripped
 02 [32035bad] (100/1058) Accurately ripped
 03 [65a971d8] (099/1062) Accurately ripped
 04 [70cb3d68] (100/1064) Accurately ripped
 05 [fb0cd9de] (099/1066) Accurately ripped
 06 [904a63bd] (099/1064) Accurately ripped
 07 [9eff1f93] (100/1066) Accurately ripped
 08 [f4ceb1ef] (099/1059) Accurately ripped
 09 [5d8a7e64] (097/1061) Accurately ripped
 10 [a869e105] (094/1061) Accurately ripped
[color=#FF0000]Offsetted by -1939:[/color]
 01 [b1ff0bf2] (013/1064) Accurately ripped
 02 [c61f3b1b] (013/1058) Accurately ripped
 03 [3096da5d] (013/1062) Accurately ripped
 04 [e9617cd1] (013/1064) Accurately ripped
 05 [f9541edf] (012/1066) Accurately ripped
 06 [61b215ea] (013/1064) Accurately ripped
 07 [66cf6126] (013/1066) Accurately ripped
 08 [e833ecc9] (012/1059) Accurately ripped
 09 [0cbf8218] (013/1061) Accurately ripped
 10 [a5a94a0a] (012/1061) Accurately ripped
[color=#FF0000]Offsetted by -1636:[/color]
 01 [acfcd391] (002/1064) Accurately ripped
 02 [55a161c9] (002/1058) Accurately ripped
 03 [9ddbd634] (002/1062) Accurately ripped
 04 [6f3cdef4] (002/1064) Accurately ripped
 05 [7622e88d] (002/1066) Accurately ripped
 06 [cf3662ae] (002/1064) Accurately ripped
 07 [b2276b57] (002/1066) Accurately ripped
 08 [a7c6f8a0] (002/1059) Accurately ripped
 09 [c3aa434b] (002/1061) Accurately ripped
 10 [84fbdf95] (002/1061) Accurately ripped
[color=#FF0000]Offsetted by -1628[/color]:
 01 [1ef7a895] (002/1064) Accurately ripped
 02 [09704e5d] (002/1058) Accurately ripped
 03 [69d384fc] (002/1062) Accurately ripped
 04 [3a2a295c] (002/1064) Accurately ripped
 05 [ea7afb95] (002/1066) Accurately ripped
 06 [9ccb1d56] (002/1064) Accurately ripped
 07 [d518004f] (002/1066) Accurately ripped
 08 [a12f4c18] (002/1059) Accurately ripped
 09 [13618e75] (002/1061) Accurately ripped
 10 [2cd0c79f] (002/1061) Accurately ripped
[color=#FF0000]Offsetted by -1614[/color]:
 01 [a9c0bfa6] (002/1064) Accurately ripped
 02 [03b4ebc2] (002/1058) Accurately ripped
 03 [4ec4f6da] (002/1062) Accurately ripped
 04 [9d496b92] (002/1064) Accurately ripped
 05 [af4cab41] (002/1066) Accurately ripped
 06 [c46a63e6] (002/1064) Accurately ripped
 07 [523d0501] (002/1066) Accurately ripped
 08 [95a5de2a] (002/1059) Accurately ripped
 09 [fab0a9a9] (002/1061) Accurately ripped
 10 [92869d5f] (002/1061) Accurately ripped
[color=#FF0000]Offsetted by -1602[/color]:
 01 [106228cc] (003/1064) Accurately ripped
 02 [907e4d5c] (003/1058) Accurately ripped
 03 [80b87d06] (003/1062) Accurately ripped
 04 [cdad5b2e] (003/1064) Accurately ripped
 05 [bb5f7c31] (003/1066) Accurately ripped
 06 [78947bae] (003/1064) Accurately ripped
 07 [06a5e475] (003/1066) Accurately ripped
 08 [8bc25b5e] (003/1059) Accurately ripped
 09 [5822de69] (003/1061) Accurately ripped
 10 [0e4878e3] (003/1061) Accurately ripped
[color=#FF0000]Offsetted by -1584:[/color]
 01 [5853e30f] (002/1064) Accurately ripped
 02 [62605e17] (002/1058) Accurately ripped
 03 [cba5c648] (002/1062) Accurately ripped
 04 [96434298] (002/1064) Accurately ripped
 05 [f22cea00] (002/1066) Accurately ripped
 06 [86a01f23] (002/1064) Accurately ripped
 07 [154333a3] (002/1066) Accurately ripped
 08 [7ced172c] (002/1059) Accurately ripped
 09 [76ea92d6] (002/1061) Accurately ripped
 10 [47d941c2] (002/1061) Accurately ripped
[color=#FF0000]Offsetted by -1334[/color]:
 01 [a43ab9f0] (038/1064) Accurately ripped
 02 [b2642534] (036/1058) Accurately ripped
 03 [31a1dc32] (036/1062) Accurately ripped
 04 [5bba97ca] (036/1064) Accurately ripped
 05 [ccd23ad4] (036/1066) Accurately ripped
 06 [c72fa0e3] (036/1064) Accurately ripped
 07 [192162e9] (036/1066) Accurately ripped
 08 [aee94792] (036/1059) Accurately ripped
 09 [7d3d7003] (036/1061) Accurately ripped
 10 [5d410e81] (036/1061) Accurately ripped
[color=#FF0000]Offsetted by -1154[/color]:
 01 [d86928c2] (002/1064) Accurately ripped
 02 [af8914b2] (002/1058) Accurately ripped
 03 [1ee6b8c6] (002/1062) Accurately ripped
 04 [3195a1ee] (002/1064) Accurately ripped
 05 [1e998cb5] (002/1066) Accurately ripped
 06 [6d1d7852] (002/1064) Accurately ripped
 07 [ab467ab5] (002/1066) Accurately ripped
 08 [1a949d9e] (002/1059) Accurately ripped
 09 [1d6ac354] (002/1061) Accurately ripped
 10 [694b9efc] (002/1061) Accurately ripped
[color=#FF0000]Offsetted by -1063[/color]:
 01 [765cc1f7] (005/1064) Accurately ripped
 02 [0cd9a522] (004/1058) Accurately ripped
 03 [6f081ce9] (004/1062) Accurately ripped
 04 [b5e0d04d] (004/1064) Accurately ripped
 05 [aa6e76c7] (005/1066) Accurately ripped
 06 [05b9dd52] (005/1064) Accurately ripped
 07 [d8b7193a] (004/1066) Accurately ripped
 08 [4f975313] (004/1059) Accurately ripped
 09 [1f286f36] (004/1061) Accurately ripped
 10 [6d31c816] (004/1061) Accurately ripped
[color=#FF0000]Offsetted by -993[/color]:
 01 [012151a9] (003/1064) Accurately ripped
 02 [cc434a8e] (003/1058) Accurately ripped
 03 [e7bf563f] (002/1062) Accurately ripped
 04 [a57d1b5b] (003/1064) Accurately ripped
 05 [e1456024] (002/1066) Accurately ripped
 06 [d6b4e909] (003/1064) Accurately ripped
 07 [4a7030b4] (003/1066) Accurately ripped
 08 [15e82d6d] (003/1059) Accurately ripped
 09 [182e62f7] (003/1061) Accurately ripped
 10 [6267b049] (002/1061) Accurately ripped
[color=#FF0000]Offsetted by -964[/color]:
 01 [fd578d2d] (004/1064) Accurately ripped
 02 [d812ec95] (004/1058) Accurately ripped
 03 [8b212fd4] (004/1062) Accurately ripped
 04 [05194914] (004/1064) Accurately ripped
 05 [a5b1e603] (004/1066) Accurately ripped
 06 [60a6e958] (004/1064) Accurately ripped
 07 [29184cb7] (004/1066) Accurately ripped
 08 [7e025c00] (004/1059) Accurately ripped
 09 [bd2234e0] (004/1061) Accurately ripped
 10 [2135b78c] (004/1061) Accurately ripped
[color=#FF0000]Offsetted by -676[/color]:
 01 [dfe53a18] (023/1064) Accurately ripped
 02 [07e2a526] (023/1058) Accurately ripped
 03 [39f5c3f4] (023/1062) Accurately ripped
 04 [8e77bfb4] (023/1064) Accurately ripped
 05 [c2a96f5f] (023/1066) Accurately ripped
 06 [3aba754c] (023/1064) Accurately ripped
 07 [12ed3f97] (023/1066) Accurately ripped
 08 [90ae18e0] (023/1059) Accurately ripped
 09 [8f1b9c9c] (023/1061) Accurately ripped
 10 [aea9e534] (023/1061) Accurately ripped
[color=#FF0000]Offsetted by -667[/color]:
 01 [176b05a6] (063/1064) Accurately ripped
 02 [f2381da7] (062/1058) Accurately ripped
 03 [df6c6895] (064/1062) Accurately ripped
 04 [f2c2b369] (064/1064) Accurately ripped
 05 [f27db184] (065/1066) Accurately ripped
 06 [4278b71d] (062/1064) Accurately ripped
 07 [1a3be72e] (064/1066) Accurately ripped
 08 [094376c7] (064/1059) Accurately ripped
 09 [719c4629] (064/1061) Accurately ripped
 10 [4a093dc3] (064/1061) Accurately ripped
[color=#FF0000]Offsetted by -665[/color]:
 01 [99aafb76] (002/1064) Accurately ripped
 02 [5f3654e5] (002/1058) Accurately ripped
 03 [926a5447] (002/1062) Accurately ripped
 04 [257e0603] (002/1064) Accurately ripped
 05 [f6466e17] (002/1066) Accurately ripped
 06 [b5fee226] (002/1064) Accurately ripped
 07 [e2f80c6c] (002/1066) Accurately ripped
 08 [079d8ba5] (002/1059) Accurately ripped
 09 [276f65d3] (002/1061) Accurately ripped
 10 [33aa34fd] (002/1061) Accurately ripped
[color=#FF0000]Offsetted by -664[/color]:
 01 [abfcd4b2] (102/1064) Accurately ripped
 02 [95b5f084] (104/1058) Accurately ripped
 03 [6be94a20] (104/1062) Accurately ripped
 04 [bedbaf50] (104/1064) Accurately ripped
 05 [f8294c62] (104/1066) Accurately ripped
 06 [efc377a9] (104/1064) Accurately ripped
 07 [c7561f0b] (104/1066) Accurately ripped
 08 [86ca9614] (103/1059) Accurately ripped
 09 [16d9e17b] (104/1061) Accurately ripped
 10 [287bb099] (104/1061) Accurately ripped
More than 16 offsets match![color=#FF0000] (is that good or bad [too less])[/color]
[color=#008000]Offsetted by -1090:
 01 [70a78afd] (000/1064) No match (V2 was not tested)
 02 [50c82b63] (000/1058) No match (V2 was not tested)
 03 [7ea42f06] (000/1062) No match (V2 was not tested)
 04 [88fff52e] (000/1064) No match (V2 was not tested)
 05 [0f104621] (000/1066) No match (V2 was not tested)
 06 [e96d0706] (000/1064) No match (V2 was not tested)
 07 [c2cb2275] (000/1066) No match (V2 was not tested)
 08 [e5d7395e] (000/1059) No match (V2 was not tested)
 09 [deac2447] (000/1061) No match (V2 was not tested)
 10 [9b47af4d] (000/1061) No match (V2 was not tested)
Offsetted by -730:
 01 [a8afda7b] (000/1064) No match (V2 was not tested)
 02 [9276d7e1] (000/1058) No match (V2 was not tested)
 03 [592de82e] (000/1062) No match (V2 was not tested)
 04 [34b60976] (000/1064) No match (V2 was not tested)
 05 [a2a0f8dc] (000/1066) No match (V2 was not tested)
 06 [0d78e743] (000/1064) No match (V2 was not tested)
 07 [e715520d] (000/1066) No match (V2 was not tested)
 08 [bd2de576] (000/1059) No match (V2 was not tested)
 09 [1148629e] (000/1061) No match (V2 was not tested)
 10 [0847cfaa] (000/1061) No match (V2 was not tested)
Offsetted by -690:
 01 [b656b68b] (000/1064) No match
 02 [0dc1230d] (000/1058) No match
 03 [55045216] (000/1062) No match (V2 was not tested)
 04 [2b587d7e] (000/1064) No match
 05 [6a8e6482] (000/1066) No match
 06 [124e4775] (000/1064) No match
 07 [95c83ae5] (000/1066) No match
 08 [9c3786ce] (000/1059) No match
 09 [361b88eb] (000/1061) No match
 10 [4ad22275] (000/1061) No match
Offsetted by -566:
 01 [ada3d967] (000/1064) No match (V2 was not tested)
 02 [6d9c7d2d] (000/1058) No match (V2 was not tested)
 03 [ae836732] (002/1062) Accurately ripped
 04 [74b67eca] (000/1064) No match (V2 was not tested)
 05 [317a8f84] (000/1066) No match (V2 was not tested)
 06 [1788a56b] (000/1064) No match (V2 was not tested)
 07 [33593fe9] (000/1066) No match (V2 was not tested)
 08 [36089492] (002/1059) Accurately ripped
 09 [50fc0361] (002/1061) Accurately ripped
 10 [dd9f0087] (002/1061) Accurately ripped
Offsetted by -120:
 01 [f0b7cd88] (000/1064) No match
 02 [e8a4d346] (000/1058) No match
 03 [99b3b740] (000/1062) No match
 04 [a5e372f0] (000/1064) No match
 05 [d82d4479] (000/1066) No match
 06 [152cbf42] (000/1064) No match
 07 [0f3db0eb] (000/1066) No match
 08 [c680c1f4] (000/1059) No match
 09 [69ac50f5] (000/1061) No match
 10 [c0bc2dc7] (000/1061) No match (V2 was not tested)
Offsetted by -108:
 01 [e5636700] (000/1064) No match (V2 was not tested)
 02 [7248122a] (000/1058) No match (V2 was not tested)
 03 [cba73d6c] (000/1062) No match (V2 was not tested)
 04 [d647628c] (000/1064) No match (V2 was not tested)
 05 [4c9b3797] (000/1066) No match (V2 was not tested)
 06 [c95bb4dc] (000/1064) No match (V2 was not tested)
 07 [c3a6905f] (000/1066) No match (V2 was not tested)
 08 [bc9d3f28] (000/1059) No match (V2 was not tested)
 09 [96a4eb52] (000/1061) No match (V2 was not tested)
 10 [3f5ce68e] (000/1061) No match (V2 was not tested)
Offsetted by -66:
 01 [00fc61a4] (002/1064) Accurately ripped
 02 [542e6ae0] (000/1058) No match (V2 was not tested)
 03 [7a7b9306] (000/1062) No match (V2 was not tested)
 04 [ffa5292e] (002/1064) Accurately ripped
 05 [8b27f9b8] (002/1066) Accurately ripped
 06 [3e4c0e8f] (002/1064) Accurately ripped
 07 [3b159e75] (002/1066) Accurately ripped
 08 [9a00f55e] (002/1059) Accurately ripped
 09 [50c5922e] (002/1061) Accurately ripped
 10 [799eea32] (002/1061) Accurately ripped
Offsetted by -30:
 01 [e6375ee4] (000/1064) No match (V2 was not tested)
 02 [ee1f1ed4] (000/1058) No match (V2 was not tested)
 03 [1056258a] (000/1062) No match (V2 was not tested)
 04 [90d0f802] (000/1064) No match (V2 was not tested)
 05 [84343668] (000/1066) No match (V2 was not tested)
 06 [5845eb0f] (000/1064) No match (V2 was not tested)
 07 [58503cd1] (000/1066) No match (V2 was not tested)
 08 [7c566cfa] (000/1059) No match (V2 was not tested)
 09 [60f4eea6] (000/1061) No match (V2 was not tested)
 10 [f2900f3e] (000/1061) No match (V2 was not tested)
Offsetted by 6:
 01 [214d8abc] (000/1064) No match
 02 [80e2cc8c] (000/1058) No match
 03 [a630b80e] (000/1062) No match
 04 [21fcc6d6] (000/1064) No match
 05 [11759283] (003/1066) Accurately ripped
 06 [716bc4b4] (000/1064) No match
 07 [758adb2d] (002/1066) Accurately ripped
 08 [5eabe496] (002/1059) Accurately ripped
 09 [effbaaf0] (002/1061) Accurately ripped
 10 [685d3308] (002/1061) Accurately ripped
Offsetted by 588:
 01 [67b08413] (000/1064) No match (V2 was not tested)
 02 [99e0c253] (000/1058) No match
 03 [1cd3a364] (000/1062) No match
 04 [ccebabe4] (000/1064) No match
 05 [4fcbacca] (000/1066) No match
 06 [f7664011] (000/1064) No match
 07 [a36930a7] (000/1066) No match
 08 [7f119cf0] (000/1059) No match
 09 [4450d6eb] (000/1061) No match
 10 [feeee415] (000/1061) No match[/color]

[color=#FF0000]Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [FEA3664E] [4BEABE1F]  
 01  99.9 [47355552] [8C8499BC]  CRC32 
 02  99.9 [7A2C30ED] [E3D95218]  CRC32 
 03  99.9 [36C7F7C3] [F0987C03]  CRC32 
 04  99.9 [DA3F795B] [BDF6906E]  CRC32 
 05  100.0 [C16BCE47] [6FB38E1A]  CRC32 
 06  99.9 [7986A29D] [8C2D58AC]  CRC32 
 07  82.2 [FB11FE06] [43C78EA8]  CRC32 
 08  99.9 [ABC0DE84] [3F6B6B30]  CRC32 
 09  99.9 [17488E08] [B0AE783D]  CRC32 
 10  99.9 [BD0866A2] [839BD1D3]  CRC32 [/color]

Would you please tell me what should I search for in all that "poem" to make sure the rip is perfect and 100% identical to the CD quality.. Also, explain to me please, what do colored parts mean and especially the green part where I'm having a lot of "no match" results...

I'm a bit of a noobie, so I'm trying to learn
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-25 18:04:40
Please put logs in a code box!
see http://www.cuetools.net/wiki/CUETools_log (http://www.cuetools.net/wiki/CUETools_log) (same link I gave you [a href='index.php?act=findpost&pid=832274']here[/a]).
Everything up to the first red text is your disc reported from 2 databases. Everything from the first red text through the green text are alternate records under the same ID (but not your disc) and are provided in case there were no AccurateRip records matching the exact pressing of your disc.  From the first red text to the green text are ARv1 alternate pressings (http://wiki.hydrogenaudio.org/index.php?title=AccurateRip#Pressings) which may or may not 100% match your disc. The green section can be alternate pressings or alternate mastering (including different in peak levels). The bottom red section is explained in the first link (bottom of page).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: whysoserious on 2013-04-25 18:24:43
Please put logs in a code box!
see http://www.cuetools.net/wiki/CUETools_log (http://www.cuetools.net/wiki/CUETools_log) (same link I gave you [a href='index.php?act=findpost&pid=832274']here[/a]).
Everything up to the first red text is your disc reported from 2 databases. From the first red text to the green text are ARv1 alternate pressings (http://wiki.hydrogenaudio.org/index.php?title=AccurateRip#Pressings) which may or may not 100% match your disc. The green section can be alternate pressings or alternate mastering. The bottom red section is explained in the first link (bottom of page).


Sorry I put it in [codes] at first but color wouldnt show in code view so I switched to normal:)

1. But if that's the case, wouldnt all of tracks be no match not only few of them? Sorry, I'm confused now.
2.
Code: [Select]
[AccurateRip ID: 000ef298-0078238f-8909cc0a] found.
Track [ CRC | V2 ] Status
01 [2035f107|e17eac17] (200+114/1064) Accurately ripped


what does (200+114/1064) mean? Only 200+114 out of 1064 rips in the database match my rip? or? If so, is it not too few? It should be a number a little closer to that 1064 surely? or I don't know what I'm talking about here..?

Explain like you are explaining to your uneducated child or something, explain like you are explaining to a noob  I need to understand that.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-25 18:41:27
Quote
Sorry I put it in [codes] at first but color wouldnt show in code view so I switched to normal:)
Color can be edited into the code box same as it can inside quotes.

1. I edited my post. Sometimes CDs are normalized on alternate pressings thus raising the levels on some tracks but not all. This can change the CRCs on some tracks but not all. Alternately a small defect can be introduced into the master plate that will slightly alter future pressings.
2. Yes that means 314 (200+114) out of 1064 total rips in the database match your pressing but as you already noted there were more than 16 alternate pressings included in that 1064 total figure.

Try it with Verbose off (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_AccurateRip). That will show combined matches across pressings. (Individual matches at 0(nnn) are your disc. If 0(nnn) appears twice, one is ARv1 and the other ARv2).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: o770 on 2013-04-26 03:13:57
Hello there. Which one of these both rips is actually accurate?
AR Confidence equals 1 for each of these rips... How trustworthy is that? I ask because today the AR database for another CD was actually missing one track(!), just check the last log below.

Your software seems great to me, I really enjoyed it!

RIP 1
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 25. April 2013, 18:11

Adoniran Barbosa / Meus Momentos

Used drive  : HL-DT-ST DVD+-RW GT10N  Adapter: 1  ID: 0

Read mode   : Secure
Utilize accurate stream : Yes
Defeat audio cache   : Yes
Make use of C2 pointers : No

Read offset correction   : 102
Overread into Lead-In and Lead-Out   : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations   : Yes
Used interface   : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format   : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  |  0:00.00 |  2:43.50 | 0 | 12274 
2  |  2:43.50 |  4:02.37 | 12275 | 30461 
3  |  6:46.12 |  3:06.20 | 30462 | 44431 
4  |  9:52.32 |  2:21.50 | 44432 | 55056 
5  | 12:14.07 |  2:31.50 | 55057 | 66431 
6  | 14:45.57 |  2:17.35 | 66432 | 76741 
7  | 17:03.17 |  2:42.58 | 76742 | 88949 
8  | 19:46.00 |  2:53.70 | 88950 |  101994 
9  | 22:39.70 |  1:58.37 | 101995 |  110881 
  10  | 24:38.32 |  2:44.43 | 110882 |  123224 
  11  | 27:23.00 |  2:20.37 | 123225 |  133761 
  12  | 29:43.37 |  3:33.03 | 133762 |  149739 
  13  | 33:16.40 |  3:09.67 | 149740 |  163981 
  14  | 36:26.32 |  2:24.00 | 163982 |  174781 
  15  | 38:50.32 |  3:20.50 | 174782 |  189831 
  16  | 42:11.07 |  3:45.65 | 189832 |  206771 
  17  | 45:56.72 |  3:12.23 | 206772 |  221194 


Range status and errors

Selected range

Filename D:\Upload\Adoniran Barbosa - Meus Momentos\Adoniran Barbosa - Meus Momentos.wav

Peak level 100.0 %
Range quality 100.0 %
Copy CRC BCC3BBB0
Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 1)  [EBDCC155]
Track  2  accurately ripped (confidence 1)  [BDD68958]
Track  3  accurately ripped (confidence 1)  [A35D337A]
Track  4  accurately ripped (confidence 1)  [BA751898]
Track  5  accurately ripped (confidence 1)  [F9DE4D42]
Track  6  accurately ripped (confidence 1)  [7340CA2D]
Track  7  accurately ripped (confidence 1)  [292EF13C]
Track  8  accurately ripped (confidence 1)  [E24F5755]
Track  9  accurately ripped (confidence 1)  [58EFE2FB]
Track 10  accurately ripped (confidence 1)  [F940935E]
Track 11  accurately ripped (confidence 1)  [45148C49]
Track 12  accurately ripped (confidence 1)  [97C2C4D3]
Track 13  accurately ripped (confidence 1)  [2C506723]
Track 14  accurately ripped (confidence 1)  [6CA1E898]
Track 15  accurately ripped (confidence 1)  [F5B1FE9C]
Track 16  accurately ripped (confidence 1)  [5B6BCA5B]
Track 17  cannot be verified as accurate (confidence 1)  [F476340E], AccurateRip returned [478E8581]

16 track(s) accurately ripped

Some tracks could not be verified as accurate

End of status report
Code: [Select]
[CUETools log; Date: 4/25/2013 18:11:25; Version: 2.1.4]
[CTDB TOCID: Y196.11voKgfRSsf2WYAiFLkYM4-] found.
Track | CTDB Status
  1  | (1/1) Accurately ripped
  2  | (1/1) Accurately ripped
  3  | (1/1) Accurately ripped
  4  | (1/1) Accurately ripped
  5  | (1/1) Accurately ripped
  6  | (1/1) Accurately ripped
  7  | (1/1) Accurately ripped
  8  | (1/1) Accurately ripped
  9  | (1/1) Accurately ripped
 10  | (1/1) Accurately ripped
 11  | (1/1) Accurately ripped
 12  | (1/1) Accurately ripped
 13  | (1/1) Accurately ripped
 14  | (1/1) Accurately ripped
 15  | (1/1) Accurately ripped
 16  | (1/1) Accurately ripped
 17  | (1/1) Accurately ripped
[AccurateRip ID: 001dc335-017764ae-060b8511] found.
Track  [  CRC  |  V2  ] Status
 01 [ebdcc155|3350e43f] (1+0/1) Accurately ripped
 02 [bdd68958|a7dea098] (1+0/1) Accurately ripped
 03 [a35d337a|a70b5297] (1+0/1) Accurately ripped
 04 [ba751898|a1154130] (1+0/1) Accurately ripped
 05 [f9de4d42|c1f64f5e] (1+0/1) Accurately ripped
 06 [7340ca2d|303e6095] (1+0/1) Accurately ripped
 07 [292ef13c|a0118b4d] (1+0/1) Accurately ripped
 08 [e24f5755|c393c33b] (1+0/1) Accurately ripped
 09 [58efe2fb|8ab95d9b] (1+0/1) Accurately ripped
 10 [f940935e|c67caa17] (1+0/1) Accurately ripped
 11 [45148c49|2cb93ff5] (1+0/1) Accurately ripped
 12 [97c2c4d3|4d528d68] (1+0/1) Accurately ripped
 13 [2c506723|7259ce0a] (1+0/1) Accurately ripped
 14 [6ca1e898|1340205b] (1+0/1) Accurately ripped
 15 [f5b1fe9c|556b347a] (1+0/1) Accurately ripped
 16 [5b6bca5b|ea49f36e] (1+0/1) Accurately ripped
 17 [f476340e|2980345e] (0+0/1) No match

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [BCC3BBB0] [5BE86576]  
 01  100.0 [5AE806D5] [FE7CDC53]  
 02  100.0 [3692493D] [8F0FF0FA]  
 03  99.9 [629D6A63] [73099B35]  
 04  99.9 [9ADDDB05] [070E8ED5]  
 05  100.0 [4ABEFEF6] [4CB76C1F]  
 06  100.0 [FD9F2E00] [F6774FE9]  
 07  100.0 [490A511D] [6A48F7CE]  
 08  100.0 [7883EF5A] [47A17C42]  
 09  100.0 [66F7F906] [0E68944B]  
 10  100.0 [6E9EC68A] [D15836BB]  
 11  100.0 [75BD8E9E] [F00C44D2]  
 12  100.0 [633213E7] [06424AF0]  
 13  100.0 [D1D4249B] [C91D4F2B]  
 14  99.9 [FCB4545E] [957C18D7]  
 15  99.9 [CCB2392D] [0073C1BB]  
 16  100.0 [552F4048] [8A580C9E]  
 17  89.1 [9A5A1BF2] [4FFAFA0B]
[/size]

RIP 2
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 25. April 2013, 20:00

Carnaval / Sambas Enredo Grupo Especial 1995 São Paulo

Used drive  : HL-DT-ST DVD+-RW GT10N  Adapter: 1  ID: 0

Read mode   : Secure
Utilize accurate stream : Yes
Defeat audio cache   : Yes
Make use of C2 pointers : No

Read offset correction   : 102
Overread into Lead-In and Lead-Out   : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations   : Yes
Used interface   : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format   : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  |  0:00.00 |  4:32.60 | 0 | 20459 
2  |  4:32.60 |  4:30.10 | 20460 | 40719 
3  |  9:02.70 |  4:33.68 | 40720 | 61262 
4  | 13:36.63 |  4:33.37 | 61263 | 81774 
5  | 18:10.25 |  4:33.35 | 81775 |  102284 
6  | 22:43.60 |  4:33.65 | 102285 |  122824 
7  | 27:17.50 |  4:32.15 | 122825 |  143239 
8  | 31:49.65 |  4:33.70 | 143240 |  163784 
9  | 36:23.60 |  4:31.00 | 163785 |  184109 
  10  | 40:54.60 |  4:21.50 | 184110 |  203734 


Range status and errors

Selected range

Filename D:\Upload\Carnaval - Sambas Enredo Grupo Especial 1995 São Paulo\Carnaval - Sambas Enredo Grupo Especial 1995 São Paulo.wav

Peak level 100.0 %
Range quality 100.0 %
Copy CRC 5040A6E6
Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 1)  [D6C8A8FB]
Track  2  accurately ripped (confidence 1)  [BC3CF057]
Track  3  cannot be verified as accurate (confidence 1)  [9A9A5D0C], AccurateRip returned [01CF11FA]
Track  4  accurately ripped (confidence 1)  [65682432]
Track  5  accurately ripped (confidence 1)  [197F40D7]
Track  6  accurately ripped (confidence 1)  [E2ECF2F2]
Track  7  accurately ripped (confidence 1)  [48244138]
Track  8  accurately ripped (confidence 1)  [5A85AE01]
Track  9  accurately ripped (confidence 1)  [15AFB58D]
Track 10  accurately ripped (confidence 1)  [D782BE8E]

 9 track(s) accurately ripped

Some tracks could not be verified as accurate

End of status report
Code: [Select]
[CUETools log; Date: 4/25/2013 20:00:03; Version: 2.1.4]
[CTDB TOCID: 1bY_ar7Ln7xO5oYGf60PpA2h8g4-] disk not present in database.
[AccurateRip ID: 00112766-00893797-880a9c0a] found.
Track  [  CRC  |  V2  ] Status
 01 [d6c8a8fb|cb59c60d] (0+1/1) Accurately ripped
 02 [bc3cf057|2c3d8d94] (0+1/1) Accurately ripped
 03 [9a9a5d0c|30f1bec7] (0+0/1) No match
 04 [65682432|8ea75dfc] (0+1/1) Accurately ripped
 05 [197f40d7|243ac2ef] (0+1/1) Accurately ripped
 06 [e2ecf2f2|a82ec81a] (0+1/1) Accurately ripped
 07 [48244138|3d1c726b] (0+1/1) Accurately ripped
 08 [5a85ae01|33d323d2] (0+1/1) Accurately ripped
 09 [15afb58d|fe2bbf57] (0+1/1) Accurately ripped
 10 [d782be8e|07d2b72c] (0+1/1) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [5040A6E6] [0D2852E1]  
 01  100.0 [44F2AB77] [FE51DD52]  
 02  100.0 [8BCB0870] [70BD74D8]  
 03  100.0 [83806274] [70E9E2D8]  
 04  100.0 [66F8B4DD] [CE80AC13]  
 05  100.0 [069E3EEF] [BE3940CD]  
 06  100.0 [6F57D696] [51A21451]  
 07  100.0 [6CABD1D1] [13F67B3E]  
 08  100.0 [3C247622] [0396E488]  
 09  100.0 [E1163A99] [BBE62AA1]  
 10  100.0 [3C952DCC] [F471BB7E]
[/size]

Should this ever happen?
RIP 3
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 25. April 2013, 22:16

Raul Seixas / Série Grandes Nomes

Used drive  : HL-DT-ST DVD+-RW GT10N  Adapter: 1  ID: 0

Read mode   : Secure
Utilize accurate stream : Yes
Defeat audio cache   : Yes
Make use of C2 pointers : No

Read offset correction   : 102
Overread into Lead-In and Lead-Out   : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations   : Yes
Used interface   : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format   : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  |  0:00.00 |  3:49.42 | 0 | 17216 
2  |  3:49.42 |  3:14.25 | 17217 | 31791 
3  |  7:03.67 |  3:49.55 | 31792 | 49021 
4  | 10:53.47 |  3:53.23 | 49022 | 66519 
5  | 14:46.70 |  2:52.07 | 66520 | 79426 
6  | 17:39.02 |  2:06.28 | 79427 | 88904 
7  | 19:45.30 |  2:59.07 | 88905 |  102336 
8  | 22:44.37 |  4:50.35 | 102337 |  124121 
9  | 27:34.72 |  2:08.40 | 124122 |  133761 
  10  | 29:43.37 |  2:33.10 | 133762 |  145246 
  11  | 32:16.47 |  2:12.70 | 145247 |  155216 
  12  | 34:29.42 |  3:45.28 | 155217 |  172119 
  13  | 38:14.70 |  1:49.62 | 172120 |  180356 
  14  | 40:04.57 |  4:49.52 | 180357 |  202083 


Range status and errors

Selected range

Filename D:\Upload\Raul Seixas - Série Grandes Nomes\D2\Raul Seixas - Série Grandes Nomes Disco 2.wav

Peak level 98.8 %
Range quality 100.0 %
Copy CRC 640C2785
Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 2)  [BB67BFFB]
Track  2  accurately ripped (confidence 2)  [E1B9DB0D]
Track  3  accurately ripped (confidence 2)  [42AC4225]
Track  4  accurately ripped (confidence 2)  [531A58A9]
Track  5  accurately ripped (confidence 2)  [84AE13A4]
Track  6  accurately ripped (confidence 2)  [E6C099E1]
Track  7  accurately ripped (confidence 2)  [A6EC4917]
Track  8  accurately ripped (confidence 2)  [95FA2B79]
Track  9  accurately ripped (confidence 2)  [6D945C7D]
Track 10  accurately ripped (confidence 2)  [2008C23C]
Track 11  accurately ripped (confidence 2)  [8451D270]
Track 12  accurately ripped (confidence 2)  [A0816C99]
Track 13  accurately ripped (confidence 2)  [462FD5F0]
Track 14  not present in database

13 track(s) accurately ripped
 1 track(s) not present in the AccurateRip database

Some tracks could not be verified as accurate

End of status report
[/size]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-26 05:35:27
I'm sure Gregory appreciates that you like the software.
Confidence 1 is unreliable unless all tracks are a match for your rip and you know for sure that you didn't submit the previous rip. It is possible that the confidence 1 entry may have errors or ripped from a CDR copy but chances are slim that your rip and an existing rip in the database submitted by someone else would have the exact same errors. It is more likely that because the rips match, both are good. However, to be certain that you didn't submit the previous rip, Confidence 2 would be more reliable when determining accuracy.

Rip 1: Using the above thinking the rip would be accurate according to CTDB (if you didn't submit the CTDB entry last October using EAC with the v2.1.3 CTDB plugin). Including your recent entry, the CTDB confidence is now 2. The AccurateRip summary is unreliable until there are more entries.

Rip 2 cannot be determined. Neither database has enough matching entries for all the tracks.

Rip 3 (see spoon's replies in this discussion (http://forum.dbpoweramp.com/archive/index.php?t-20464.html)). The last track was probably put into limbo awaiting a third rip because the two previous rips of that track had different CRCs. Determining accuracy would be the same as Rip 2.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: o770 on 2013-04-26 06:26:21
That was so definite and concise. Thanks a lot! I wonder how you found the month for the other rip submission to CTDB. By the way that wasn't me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: whysoserious on 2013-04-26 12:40:13
Code: [Select]
[CUETools log; Date: 26.4.2013 г. 14:36:36; Version: 2.1.4]
[CTDB TOCID: rrrcDFrz03RW_9pI5jGgaedgM3w-] found.
Track | CTDB Status
  1  | (2/3) Accurately ripped
  2  | (2/3) Accurately ripped
  3  | (2/3) Accurately ripped
  4  | (2/3) Accurately ripped
  5  | (1/3) Accurately ripped, or (1/3) differs in 1 samples @01:59:58
  6  | (2/3) Accurately ripped
  7  | (2/3) Accurately ripped
  8  | (2/3) Accurately ripped
  9  | (2/3) Accurately ripped
 10  | (2/3) Accurately ripped
 11  | (2/3) Accurately ripped
 12  | (2/3) Accurately ripped
 13  | (2/3) Accurately ripped
[AccurateRip ID: 001eb2e8-0131985e-b40e8d0d] found.
Track  [  CRC  |  V2  ] Status
 01 [c755b4c6|0caab4de] (2+0/2) Accurately ripped
 02 [9572e449|a39d86c8] (2+0/2) Accurately ripped
 03 [ce32335f|522f8916] (2+0/2) Accurately ripped
 04 [5b75ecf9|c8773bf1] (2+0/2) Accurately ripped
 05 [cdc54c48|bf97513c] (0+0/2) No match
 06 [bbcd4a0a|4665fe1c] (2+0/2) Accurately ripped
 07 [1e03681c|0e8f83b7] (2+0/2) Accurately ripped
 08 [591278e6|69e0f120] (2+0/2) Accurately ripped
 09 [9012f725|edf747d1] (2+0/2) Accurately ripped
 10 [e451a258|4b4755ee] (2+0/2) Accurately ripped
 11 [1fc341dd|2726a2f0] (2+0/2) Accurately ripped
 12 [27c06198|774407ba] (2+0/2) Accurately ripped
 13 [54b2e822|ade8f175] (2+0/2) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [BDFBF8CF] [5346D7BE]  
 01  100.0 [F1C395A7] [053B0676]  CRC32 
 02  100.0 [18A1624B] [F9E47B2A]  CRC32 
 03  100.0 [BE3E579E] [6661AAD9]  CRC32 
 04  100.0 [E705F545] [15507A04]  CRC32 
 05  100.0 [4130FC27] [40612787] [BEFF88CF]
 06  100.0 [E4F4D2D1] [DF9C9537]  CRC32 
 07  100.0 [357369A5] [B1315784]  CRC32 
 08  100.0 [75CEA681] [5CAA4E7A]  CRC32 
 09  100.0 [A7D8A385] [B8627BA2]  CRC32 
 10  100.0 [0E96301A] [4D096B38]  CRC32 
 11  100.0 [BC1E6CE6] [A9F82FC9]  CRC32 
 12  100.0 [D793872B] [86856D94]  CRC32 
 13  100.0 [EE79EFA0] [3E62AB17]  CRC32
Coldplay's - X&Y album... Is that possible? Only 2 found rips for this album in the whole AR database?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-26 13:29:19
Database records are stored based on TOC (disc structure) not title. It looks like there are more than 25 freeDB IDs (http://musicbrainz.org/search?query=Coldplay%09X%26Y&type=freedb&method=indexed)* for this CD with 13 tracks but none match the ID of your rip. So yes it is possible you have a less popular version of the CD title.

* I didn't verify all 25+ were unique.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: whysoserious on 2013-04-26 13:47:02
Database records are stored based on TOC (disc structure) not title. It looks like there are more than 25 freeDB IDs (http://musicbrainz.org/search?query=Coldplay%09X%26Y&type=freedb&method=indexed)* for this CD with 13 tracks but none match the ID of your rip. So yes it is possible you have a less popular version of the CD title.

* I didn't verify all 25+ were unique.



So someone can actually have  "(*/1000+) Accurately ripped" of this album?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-26 15:01:16
With a different version of the disc that may be possible.
I didn't mention that a low AR confidence can also be from an incorrect AccurateRip ID calculation (http://www.cuetools.net/wiki/CUETools#What.27s_wrong_if_i.27m_sure_the_CD_is_present_in_the_database.2C_but_CUETools_doesn.27t_find_it) because I didn't see any evidence of that here.
Incorrect AccurateRip ID calculation in CUETools could be caused byI did find 2 data track versions of this title but neither matched the 13 track structure of your disc.

Note: CUETools Database CTDB TOCID calculation doesn't rely on pregap (HTOA) or data track presence.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: whysoserious on 2013-04-26 15:18:27
With a different version of the disc that may be possible.
I didn't mention that a low AR confidence can also be from an incorrect AccurateRip ID calculation because I didn't see any evidence of that here.
Incorrect AccurateRip ID calculation in CUETools could be caused by
  • A missing cue or a cue missing disc pregap (HTOA (http://wiki.hydrogenaudio.org/index.php?title=HTOA)) info for a rip of a disc that has pregap (HTOA).
  • Missing cue or missing DISCID tag in the cue or missing TOC in the EAC log or missing EAC log for a rip of a disc that has a data track.
I did find 2 data track versions of this title but neither matched the 13 track structure of your disc.

Note: CUETools Database CTDB TOCID calculation doesn't rely on pregap (HTOA) or data track presence.



I wish I had the CD and rip it myself.. Now I'm just wondering how perfect the rip I have is.

And all the info you have been giving me for the last days is getting me confused big time.. Lol.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-04-26 19:23:27
I wish I had the CD and rip it myself.. Now I'm just wondering how perfect the rip I have is.

Why? If there are bad samples, either they're creating audible problems, or they aren't. If they aren't, then it's just like we say to people who are trying to figure out ideal settings for lossy codecs like MP3: once you can't tell the difference between your copy and the original, it is, in effect, perfection, and you can't improve on it. Not having the original to compare to makes it even easier; do you hear anything weird in it, that sounds like it shouldn't be there, or not? If not, there's no problem.

(Also, if you really wish you had the CD, you could just buy a used one for the cost of a latte, shipping included. I mean we are talking about a Coldplay album, probably the most easy-to-obtain CD in the universe. Someone you know probably wants to get rid of their copy. You could probably even stand on the street and hold out your hand, and someone would give you one.  )
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: whysoserious on 2013-04-27 11:28:50
Do I lose any quality if I split a single-flac album into multiple tracks(files)? I have John Lennon's "Imagine" in a single FLAC file and someone told me to use CUETools->Encode->Tracks->FLAC->libFLAC->8->Go.. in order to do that. So, do I lose quality? It's still lossless after that right?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-04-27 12:57:49
Yes, it's still lossless. By definition, no, you don't lose quality.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2013-04-27 13:01:04
If it were really that simple you could tell that to people using medieval cue splitter.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2013-04-27 13:17:04
ITT: ‘Help me with my torrents.’
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-04-27 15:08:27
Dang it, I had blocked Medieval out of my mind.

I shouldn't have said "by definition" splitting a lossless image to lossless tracks is a lossless operation. That one particular splitter is notorious for screwing up track boundaries. CUETools splits properly, and is the only one I know of which respects HTOA (if so configured).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2013-04-27 16:10:42
I shouldn't have said "by definition" splitting a lossless image to lossless tracks is a lossless operation.

It is if the lossless formats are properly decoded and re-encoded. And those are fair assumptions to make. It is indeed the case that, by definition, lossless is lossless… unless someone has done something wrong.

So, the exception to that rule is supplied by one programmer who thought they were being clever by trying to split directly in the compressed file, despite that not being supported by the format. And it is, it seems, an error for which other people will be paying for the rest of time, in the form of having to suffix common-sense rules about lossless with a disclaimer about MCS!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2013-04-27 20:21:11
Been testing out the new v2.1.5 Dev rls and i must say it works really nice. Haven't stumbled over any issues so far when it comes to CUETools. Will get on testing CUERipper next.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: o770 on 2013-04-27 22:02:30
Hi. Where did my tracks comment tag go after ripping? You know, that comment field inside the track itself - when you click the track in Cueripper tracklist.
I used that for the release years of tracks in my compilation albums and some additional notes but it's missing in Foobar properties window after the Cue file has been loaded. Foobar only shows the album comment tag - that one from the button Meta in Cueripper.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-27 23:10:52
Known problem/bug mentioned here (http://www.cuetools.net/wiki/CUERipper_Settings#.284.29_Tracks_window). I've already let Gregory know that it still isn't working in 2.1.5.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: o770 on 2013-04-27 23:35:48
Ok... I failed to notice that. What tool do you recommend me to load the .cue file from Cueripper and fix the tags in my rips - image+.cue?
One more thing if I could, where would that comment field go if working? How can I create it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-28 00:48:26
Depending on how many you need to do, you might just edit them in. cdrcue may do it but it's not free and you might just be editing them in using that app with the REM command anyway.

Code: [Select]
REM DATE 2011
REM DISCID AAAAAAAA
PERFORMER "Various Artists"
TITLE "Title"
FILE "File.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Artist 1"
    TITLE "Title"
    [color=#FF0000]REM COMMENT "1974"[/color]
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PERFORMER "Artist 2"
    TITLE "Title"
    [color=#FF0000]REM COMMENT "1976"[/color]
    INDEX 01 00:...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: o770 on 2013-04-28 02:21:37
That works for me as long as the album comment field hasn't been used - the one in the header, just like in your example. I need something else but I guess that's for another topic. I wonder how Cueripper could manage both fields since they are presented separated in the GUI.
Thanks a lot, korth!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a3aan on 2013-04-28 10:29:50
Still hoping for writing of CTDB Accuracy values tags. Just like AccurateRip values tags. Any chance? Cheers, Adriaan.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: unfinished.hide on 2013-04-28 11:26:29
Regarding the complete integration between CueTools and CTDB, I am missing the "encode if verified" script to take into account the CTDB submissions as well since it seems to be already quite mature, and sometimes, even more useful than AR (especially for new releases). Hope it is in Gregory's plans for a future version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-28 17:57:13
Hi. Where did my tracks comment tag go after ripping? You know, that comment field inside the track itself - when you click the track in Cueripper tracklist.
I used that for the release years of tracks in my compilation albums and some additional notes but it's missing in Foobar properties window after the Cue file has been loaded. Foobar only shows the album comment tag - that one from the button Meta in Cueripper.

It was supposed to be written as a tag. It will be fixed it in official release.

I'm not sure about per-track 'REM COMMENT' in CUESheet. CUESheets are not supposed to handle advanced tagging.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ThePampers on 2013-04-28 18:09:45
A special thanks to Gregory for the new (incoming) version  ...
One question : how can i change the 'totaltrack' & 'totaldisc' tags with the reference standard 'tracktotal' & 'disktotal' during the flac creation ?
'Albumartist' tag is supported ? In the setting file i don't see anything...
Any chance in future to see the option 'capitalize first letter' in the tags option ?
Thanks in advance .


Anyone can help me  ?
Tnx.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-28 18:18:53
I'm not sure about per-track 'REM COMMENT' in CUESheet.
That's just something that works in the Foobar properties window provided to satisfy
but it's missing in Foobar properties window after the Cue file has been loaded. Foobar only shows the album comment tag

If I remember correctly I got the per-track 'REM COMMENT' from the foo_cuesheet_creator component. I don't expect it to be part of CUERipper.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-28 18:20:30
"albumartist" is supported and is used instead of "artist" whenever you set different artists for different tracks.

I think i switched to 'tracktotal' & 'disktotal' because 'totaltrack' & 'totaldisc' were not supported by foobar2000.
If i'm wrong, i can just fix it. If i'm right, i will probably need to think about adding "foobar2000-compatible tagging" option.

As for 'capitalize first letter' button, i don't like it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2013-04-28 18:32:39
foobar2000 changed sometime ago to use the more widely accepted TRACKTOTAL and DISCTOTAL by default. it still has options for writing in it's older format. i think it still reads from both.

(https://dl.dropboxusercontent.com/u/22801321/2013/april/flac%20tags.png)

edit: according to the changelog, this happened in 1.1.8
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-28 18:37:06
Thanks. That's good news.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: o770 on 2013-04-28 20:11:39
So the track comment may be a field exclusive to per-track rips, added to the audio files; it would be disabled otherwise...?

I suggest having any possible tag available to the tracks separately, either for tracks and image rips.

It was supposed to be written as a tag. It will be fixed it in official release.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-28 20:31:02
Foobar has a way of keeping per-track tags in image (if it has embedded cuesheet): it uses "cue_trackNN_" prefix. That's the way cuetools stores AR tags for example.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-04-28 20:34:24
Gregory, has/or will reading TOCs in meta data make it to 2.1.5? Can't wait to be able to scan my 8000 albums!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-04-28 20:42:08
Yes
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MrSinatra on 2013-04-29 14:49:35
first, I apologize if this is the wrong place to post this, please correct me if so.

second, I want to thank the dev, as I made bad EAC rips that the "truncate offset" feature fixed! 

third, I want to report a bug, or perhaps get instruction if that's what I need:

I had made FLACs (single per track files, tagged, no cue sheets) of the beatles remasters using EAC / Flac 1.2.1 some years ago that had the offset issue.  I have since seen cuetools make new flacs out of them that play gaplessly, and so that's great.

however, one of my tag fields, TRACKNUMBER, does not seem to exist in the new flacs at all?  is that by design?  how do I get the track number in the new files tag?  (it is in the filename as well btw)

also, all my tag fields are now capitalized and reordered, such that my RG fields, for some reason, are listed first.  again, by design?

I also have other questions about cuetools and the encoders, etc, but where would be the best place to post them, as I assume its not this thread?

thanks again!!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-29 17:40:36
Did you change any of the Advanced Settings (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging)? 'Write basic tags from CUE data' needs to checked for TRACKNUMBER even if there is no Input CUE sheet (CUETools creates a 'dummy' CUE sheet if none exists).

Capitalization is likely from the metadata source. If you used a batch input mode and don't want tag data used from freedb, musicbrainz, etc., you can disable them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: MrSinatra on 2013-04-29 22:16:01
thx for the reply, I think it helped.  hope you don't mind bearing with me...

Did you change any of the Advanced Settings (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging)? 'Write basic tags from CUE data' needs to checked for TRACKNUMBER even if there is no Input CUE sheet (CUETools creates a 'dummy' CUE sheet if none exists).


yes, I did change settings, including that one.  I have to say, I find it misleading, but I do understand.  putting it back fixed it, but doing so now adds a comment field and value I don't want: "CUETools generated dummy CUE sheet"  ...can I turn that off?  it just makes work for me having to delete it afterwards.

Capitalization is likely from the metadata source. If you used a batch input mode and don't want tag data used from freedb, musicbrainz, etc., you can disable them.


I dragged a folder to the cuetools input line.  I had freedb and musicbrainz unchecked.  I think maybe I was unclear...

in the orig flac files, some of the actual FIELD-names, (not the values for the field names, but the field names themselves), are NOT capitalized.  in the new FLACs cuetools makes, they are ALL capitalized.  (again, the field names, not the values).  in addition, they are re-ordered such that the RG fields and values come first, as well as other changes.

is that typical and desired?

some other issues:

when I converted to ALAC, i noticed it embedded the artwork, even though i had that pref unchecked.  is that not a bug?  do i have to uncheck all the art options to get it not to happen on m4a?

which library for alac is the "official" one?  libALAC or ffmpeg alac?  its great to have these choices, but where can i see a pros/cons to pick between them?

at the very top, i pick "fix" but i get the feeling convert or default would yield the same result for me, in so far as fixing my offset issue; similarly, do i really need to pick "fix offset" in the action box, as it seems default does that anyway, and whats repair for?

sorry for overloading this post!  thx for the help!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-04-29 22:33:25
doing so now adds a comment field and value I don't want: "CUETools generated dummy CUE sheet"  ...can I turn that off?  it just makes work for me having to delete it afterwards.
I'd like to second that. It makes sense to put this in the .cuesheet, but why put it in the files themselves?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-04-30 00:23:15
MrSinatra,
I'll defer on the 'CUETools generated dummy CUE sheet' and 'FIELD-names' questions.

Embedded artwork does seem to be a bug and not limited to ALAC. 'Copy album art tags' AND 'Embed Folder.jpg' need to be unchecked to prevent embedded art even if the input files don't have embedded art.

ffmpeg alac is an external encoder. It was used before the built-in encoder was added. Users may still use it if they wish (the user must supply the ffmpeg.exe for it to work).

Profiles (http://www.cuetools.net/wiki/CUETools_Settings#.281.29_Profile_.7Bdrop-down_list.7D) are used to 'preset' your settings for different tasks. 'fix' is a preset for 'fix offset' which refers to 'drive offset correction' not the '[a href='index.php?act=findpost&pid=831858']compression offset[/a]' fix by truncating the extra 4608 samples. You should use the 'default' profile for that.

You can find out a little more about 'repair' here (http://www.cuetools.net/wiki/CUETools_Database).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dizzy274 on 2013-05-03 09:33:54
Hi All

First post here, so please bear with me.....

I've been running Cuetools under XP for years with no problems - recently I've switched to Windows 8 and all is ok except:-

When verifying and creating an Accuraterip log ( xxx.accuraterip ), I can't automatically overwrite it. I've ticked the box "Remember my choice" in the "Overwrite" panel, but it won't remember my choice.

This occurs with both 2.1.4 & 2.1.5.

Any ideas?

Best regards.

Ian.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-05-03 12:22:23
The "remember my choice" only seems to work for this current run, as in, you select multiple albums and it asks you if you want to overwrite the .accurip. You tick  the checkbox and it doesn't ask you for the other selected albums. I think this is intended and is not dependent on the OS version.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2013-05-03 14:13:50
oh phooey, i just bought a new drive having not had one for over a year and cueripper doesn't like it. it fetches metadata/AR/CTDB data but fails when the progress bar of detecting gaps reaches 100%.

(https://dl.dropboxusercontent.com/u/22801321/2013/may/cue%20ripper.png)

a few details: LITE-ON iHAS 524 internal sata drive, gigabyte motherboard with intel h61 chipset, windows 7 x64

i tried several disks and they all error at the same place. foobar2000 and EAC both rip those same disks just fine.

cueripper did manage to rip 1 disk though - it was an enhanced CD with 13 audio tracks and a data track. all the ones that failed are just standard audio. any ideas?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dizzy274 on 2013-05-03 14:36:46
Thanks for the reply.

I never verify multiple albums - I might verify an album, find there's not many matches and then verify it some time later. I don't recall ever having to go through the overwrite window as I do now.

I've still got XP on another partition, so I can check it out.

Thanks again.

Ian.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-03 14:48:06
Just tested XP and XP64. Overwrite Popup appears on both (same as you report [a href='index.php?act=findpost&pid=833176']here[/a] for Win8). Personally, I don't like the idea of CUETools permanently overwriting files. The temporary (per-run) setting is fine.

I always create a unique log file so I can compare results.

%filename%[' ('%unique%')'].accurip
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Micha-ASQ on 2013-05-04 08:49:43
CUERIPPER

Can i read / rip to AIFF ?
How ?

I would like to rip to AIFF as WAV to my knowledge doesn't keep the tags and AIFF can be read by iTunes, too.

Many thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2013-05-04 09:32:18
ripping to AIFF is daft when it already supports apple lossless.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-05-11 01:55:28
Gregory, has/or will reading TOCs in meta data make it to 2.1.5? Can't wait to be able to scan my 8000 albums!



Yes


So is it already in, or just planned? No change log available yet...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-05-11 01:59:46
It's already in, and change log is here: http://www.cuetools.net/wiki/CUETools_Changelog (http://www.cuetools.net/wiki/CUETools_Changelog)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ThePampers on 2013-05-11 10:50:39
It's already in, and change log is here: http://www.cuetools.net/wiki/CUETools_Changelog (http://www.cuetools.net/wiki/CUETools_Changelog)


08.05.2013: CUETools 2.1.5:
CUETools: added support for CDTOC tag to help determine pre-gap and data track info
CUETools: added button for easier access to encoder settings
CUETools: support for non-subset FLAC modes disabled by default
CUETools: built-in managed encoders (libFlake, libALAC, etc) renamed to 'cuetools' for simplicity
CUETools: CUETools FLAC decoder optimized; verification now works around 50% faster when not limited by I/O
CUETools: to simplify the interface, removed lossyWAV support; encoder was outdated anyway
CUETools: added support for WMA lossless as input and both WMA lossless and lossy as output
CUETools: cleaned up encoder/decoder pages in advanced settings
CUETools: treat batch jobs with only 1 album as non-batch, i.e. allow interactive UI, such as repair dialog
CUETools: use TRACKTOTAL, DISCTOTAL, ALBUMARTIST tags instead of old style fb2k TOTALTRACKS, TOTALDISCS, ALBUM ARTIST
CUERipper: right-click on the album art shows an enlarged fragment of it
CUERipper: clicking through all available cover art selects 'no cover art'
CUERipper: hovering over album art shows album art URL
CUERipper: track quality is correctly reported in EAC-style log
CUERipper: Test & Copy now works for drives that fail gap-detection
CUERipper: remember chosen format & offset between restarts
CUERipper: track comments saved to cue sheet
CUETools.Converter: added support for encoding to lossy formats
CUETools.Converter: added support multi-channel audio
CUETools.Converter: added support for stdin/stdout
CUETools.Converter: added support for different compression levels
ArCueDotNet.exe: added CTDB support

I love you  .
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ThePampers on 2013-05-11 16:42:32
It's possible to activate V/A button without compilation CD ?
BIG tnx.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-11 17:34:34
V/A button (freeDB only) (http://www.cuetools.net/wiki/CUERipper_Settings#.287.29_V.2FA_.28freeDB_only.29_.7Bbutton.7D)
You can edit track artist, track title and track comment (comment now working in 2.1.5) from the Tracks window (http://www.cuetools.net/wiki/CUERipper_Settings#.284.29_Tracks_window).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-05-12 18:43:39
It's already in, and change log is here: http://www.cuetools.net/wiki/CUETools_Changelog (http://www.cuetools.net/wiki/CUETools_Changelog)


Thanks, scanning now. Looks like it will take 10+ day!
A lot of submissions so far!

Feature request: Could discs that are bad be listed in RED

Also, I have had a few "database access error. The operation has timed out", if I rescan, will these be counted as recently scanned, an thus skipped, or since the operation failed will they be scanned the next time.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-05-14 19:13:52
It's already in, and change log is here: http://www.cuetools.net/wiki/CUETools_Changelog (http://www.cuetools.net/wiki/CUETools_Changelog)


08.05.2013: CUETools 2.1.5:
CUERipper: track comments saved to cue sheet


I just ripped a CD with CUERipper 2.1.5 and used a disc comment (under "Meta") and track comments for tracks 1 and 2.

The disc comment appears in the cue sheet, the two track comments do not.

Also, when looking with Mp3tag at the tags of the generated FLAC files, the field "comment" contains the disc comment for each track. Perhaps these should be substituted by the track comments, too, if there are any.

Best,
Christian
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-14 20:00:35
Quote
Quote
CUERipper: track comments saved to cue sheet
The disc comment appears in the cue sheet, the two track comments do not.

I think that was an error in the changelog and should read 'tags'. In [a href='index.php?act=findpost&pid=832645']this post[/a] Grigory was against putting track comments in the CUE.

Quote
Also, when looking with Mp3tag at the tags of the generated FLAC files, the field "comment" contains the disc comment for each track. Perhaps these should be substituted by the track comments, too, if there are any.

Could Mp3tag be substituting the disc comment for the track comment? I tested this the same way (in 'tracks' mode) and in Foobar2k the track comment field does show the comment I added for track 1 & 2 and the disc comment only shows for tracks where a track comment wasn't added.

In 'image' mode, additional tags are written to the image in the form 'CUE_TRACKnn_COMMENT' where nn is the track number. Again the track comments I added were in CUE_TRACK01_COMMENT & CUE_TRACK02_COMMENT and the remaining CUE_TRACKnn_COMMENT fields had the disc comment.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-05-14 21:36:22
Thanks for your answer!

Quote
Quote
CUERipper: track comments saved to cue sheet
The disc comment appears in the cue sheet, the two track comments do not.

I think that was an error in the changelog and should read 'tags'. In [a href='index.php?act=findpost&pid=832645']this post[/a] Grigory was against putting track comments in the CUE.


Agreed, tags seem to be more appropriate than adding this kind of info to the CUE sheet.

Quote
Quote
Also, when looking with Mp3tag at the tags of the generated FLAC files, the field "comment" contains the disc comment for each track. Perhaps these should be substituted by the track comments, too, if there are any.

Could Mp3tag be substituting the disc comment for the track comment? I tested this the same way (in 'tracks' mode) and in Foobar2k the track comment field does show the comment I added for track 1 & 2 and the disc comment only shows for tracks where a track comment wasn't added.

In 'image' mode, additional tags are written to the image in the form 'CUE_TRACKnn_COMMENT' where nn is the track number. Again the track comments I added were in CUE_TRACK01_COMMENT & CUE_TRACK02_COMMENT and the remaining CUE_TRACKnn_COMMENT fields had the disc comment.


Just tested this with foobar2k and you are completely right! So things are exactly the way they should be, and this must be an Mp3tag issue.

Thanks again!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Kevin04 on 2013-05-15 10:04:11
I just wanted to add that I can't confirm this. I testripped a disc with CUERipper 2.1.5 as seperate tracks, adding track comments for only track 1 and 2 as well as a general disc comment.
The track comments show as COMMENT in Mp3tag and foobar2000 for tracks 1 and 2 respectively, and the disc comment shows as COMMENT in Mp3tag and foobar2000 for all the other tracks.
Tried this with all included encoders except FLACCL. So if this is the intended behaviour, Mp3tag (v2.55a) works perfectly fine here. Image tags also work as described by korth.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2013-05-15 22:16:59
Gregory, while you're preparing the next version I'd like to remind you of my previous bug reports (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&view=findpost&p=805782), listed in order of how much trouble they caused me: BTW thanks again for what you've done- this really is a great tool and it's neat to see it continue to improve.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-05-18 05:05:47
How do I get CueTools to operate in verify mode and skip recently verified tracks?

I have ticked
-use CTDB
-use Local DB
-skip recently verified
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-05-18 09:23:38
4 issues in one post, here:

1. For many discs, the CTDB metadata plugin for EAC provides more matches than CUERipper does. For example, one disc I'm testing with right now:
CUERipper yields 2 MusicBrainz results, plus 1 Amazon cover image.
EAC CTDB metadata provider yields 2 MusicBrainz results, 3 Discogs results, 1 freedb result, plus 1 Amazon cover image, 3 Discogs cover images
Is this a bug in CUERipper? I'd really like to get the additional results from Discogs. Let me know if you need more info.

2. I noticed CUERipper doesn't write an EAC-style .log if the Abort button is pressed. Since CUETools can't verify an incomplete rip, I have no way to judge the quality of the tracks that were extracted before I pressed the button. I needed to press the button because I have a badly scratched track that was going to take hours to rip and possibly never complete, even in burst mode (even EAC's true 1-pass burst mode gets stuck). So it would be nice if I could at least get a .log for the aborted rip. EAC supports this.

Example A - end of EAC log for an aborted image rip:
Code: [Select]
Range status and errors

Selected range

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album).wav

    Copy aborted

End of status report

Example B - end of EAC log for an aborted tracks rip (aborted during rip of 1st track):
Code: [Select]
Track  1

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[01] Madonna - Like a Prayer (12-inch dance mix).wav

    Copy aborted

Track  2

    Copy aborted

Track  3

    Copy aborted

Track  4

    Copy aborted

Track  5

    Copy aborted

Track  6

    Copy aborted

Track  7

    Copy aborted

Track  8

    Copy aborted

No tracks could be verified as accurate

There were errors

End of status report

Example C - end of EAC log for an aborted tracks rip (track 7 skipped, track 8 aborted):
Code: [Select]
Track  1

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[01] Madonna - Like a Prayer (12-inch dance mix).wav

    Timing problem 0:00:07
    Timing problem 0:00:16

    Peak level 90.9 %
    Extraction speed 12.2 X
    Copy CRC BB31951A
    Accurately ripped (confidence 14)  [50F15151]  (AR v1)
    Copy finished

Track  2

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[02] Madonna - Like a Prayer (12-inch extended remix).wav

    Timing problem 0:00:33
    Timing problem 0:01:46

    Peak level 96.3 %
    Extraction speed 15.2 X
    Copy CRC D203844B
    Accurately ripped (confidence 14)  [DBF49FBB]  (AR v1)
    Copy finished

Track  3

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[03] Madonna - Like a Prayer (Churchapella).wav

    Peak level 62.4 %
    Extraction speed 18.1 X
    Copy CRC 0741A559
    Accurately ripped (confidence 13)  [340411CD]  (AR v1)
    Copy OK

Track  4

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[04] Madonna - Like a Prayer (12-inch club version).wav

    Peak level 100.0 %
    Extraction speed 19.7 X
    Copy CRC 1D21FAAA
    Accurately ripped (confidence 13)  [61E7D9EB]  (AR v1)
    Copy OK

Track  5

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[05] Madonna - Like a Prayer (7-inch remix edit).wav

    Peak level 96.7 %
    Extraction speed 21.2 X
    Copy CRC B18669FC
    Cannot be verified as accurate (confidence 13)  [A5AD40F0], AccurateRip returned [56F7AECF]  (AR v2)
    Copy OK

Track  6

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[06] Madonna - Express Yourself (Non-Stop Express mix).wav

    Timing problem 0:04:59

    Peak level 100.0 %
    Extraction speed 7.8 X
    Copy CRC 784D751D
    Cannot be verified as accurate (confidence 11)  [582FA4C6], AccurateRip returned [EF68639A]  (AR v2)
    Copy finished

Track  7

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[07] Madonna - Express Yourself (Stop & Go dubs).wav

    Copy aborted

Track  8

    Filename I:\incoming music\_new rips\Madonna - Remixed Prayers (Mini Album)\[08] Madonna - Express Yourself (Local mix).wav

    Timing problem 0:00:00

    Copy aborted


 4 track(s) accurately ripped
 2 track(s) could not be verified as accurate
 2 track(s) canceled

Some tracks could not be verified as accurate

There were errors

End of status report

3. The wiki says "Burst mode = Reads once, If drive reports C2 errors then Error Correcting begins and up to 15 more read retries are done." My .log says "Make use of C2 pointers : No". Yet, when I rip in burst mode, up to 15 retries happen. Is the log wrong, or should the wiki say, like it does for the other modes, "If results differ or the drive reports C2 errors..."? (I also wasn't really expecting there to be no option for traditional, 1-pass burst mode.)

4. My drive can provide C2 pointers, but CUERipper doesn't use them. So I'm still wondering how CUERipper makes this decision of whether to use them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-18 13:17:11
1. Sounds like the Metadata search in the EAC plugin (http://www.cuetools.net/wiki/CTDB_EAC_Plugin#Usage) is set to 'Extensive' and in CUERipper (http://www.cuetools.net/wiki/CUERipper_Options) is set to 'Default'.

3. "Make use of C2 pointers : No" is 'fixed text' in the EAC-style log template. It doesn't change. Remember CUERipper isn't EAC. Some parts of the EAC-style log aren't collected and stored within CUERipper. Another example is "Adapter: 1  ID: 0".

I'll leave 2. , 4. and the rest of 3. for Grigory.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-18 14:08:27
How do I get CueTools to operate in verify mode and skip recently verified tracks?

Did you mean discs? CUETools can only verify complete discs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-05-18 14:11:28
How do I get CueTools to operate in verify mode and skip recently verified tracks?

Did you mean discs? CUETools can only verify complete discs.


Yes, I meant discs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-18 14:23:19
Do setting changes stick? (remembered on restart of CUETools)
The settings and local database are located in %appdata%/CUE tools/
If setting changes don't stick, your Windows configuration may be preventing CUETools from writing to this location.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-05-18 18:58:06
If I use the database sort area I can see that many tracks are in the local DB.

However, I recently let the CT run for 3-5 days trying to verify my library. It got to the Js, but I had to restart the computer. Now it wants to start all over... And no, for what ever reason all of those discs don't seem to be showing up in the local DB.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-05-18 22:22:46
1. Sounds like the Metadata search in the EAC plugin (http://www.cuetools.net/wiki/CTDB_EAC_Plugin#Usage) is set to 'Extensive' and in CUERipper (http://www.cuetools.net/wiki/CUERipper_Options) is set to 'Default'.

Ah, you're right. I don't know how I missed that. I stared at the options multiple times, even. Thanks.

And it sounds like CUERipper is using C2 pointers with my drive, and the log is just wrong. I don't like that there is boilerplate text that misrepresents settings.

So I guess I just have feature requests:
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-20 15:21:14
However, I recently let the CT run for 3-5 days trying to verify my library. It got to the Js, but I had to restart the computer. Now it wants to start all over... And no, for what ever reason all of those discs don't seem to be showing up in the local DB.

It appears CUETools stores the data in memory and writes a temporary file at the end of the batch run when updating the localDB. If the run didn't finish due to some sort crash this data didn't get updated to the localDB. I'd suggest making smaller batch runs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-05-22 08:25:20
Perhaps someone can verify this. I get a reproducible complete crash of CUERipper 2.1.5 just by inserting (not even ripping) certain CDs, which is most probably due to their copy protection. One example is the German sampler "Partyservice 3" (EAN 731458353522):

Code: [Select]
Beschreibung:
  Stopped working

Problemsignatur:
  Problemereignisname:    CLR20r3
  Problemsignatur 01:    cueripper.exe
  Problemsignatur 02:    1.9.0.0
  Problemsignatur 03:    518b0a73
  Problemsignatur 04:    CUETools.Codecs
  Problemsignatur 05:    2.1.5.0
  Problemsignatur 06:    518afb0a
  Problemsignatur 07:    164
  Problemsignatur 08:    21
  Problemsignatur 09:    System.ArgumentException
  Betriebsystemversion:    6.1.7601.2.1.0.768.3
  Gebietsschema-ID:    1031

Lesen Sie unsere Datenschutzbestimmungen online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
  C:\Windows\system32\de-DE\erofflps.txt


Copy protected discs are so annoying ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2013-05-22 14:09:26
And it sounds like CUERipper is using C2 pointers with my drive, and the log is just wrong. I don't like that there is boilerplate text that misrepresents settings.


Setting C2 to yes is not desirable in an EAC style log. Did you try setting "EAC style log" to false in the options?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-05-22 23:04:10
Setting C2 to yes is not desirable in an EAC style log.

If C2 pointers are used, why would you want the log to say they weren't?

Did you try setting "EAC style log" to false in the options?

Well, yeah, but that produces CUERipper's native log format, which doesn't say whether C2 pointers were used at all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ligerpants on 2013-05-23 18:44:03
As a longtime user, I'm happy to see that 2.1.5 is forthcoming.  However, even in the new beta, when running Verify on .ape or .tak files, it seems like the ACCURATERIP* tags aren't being updated, as they are in .flac files.

I have tested this using embedded and track-separated .ape and .tak files, and examining/reloading tags in the latest Foobar2000. 2.1.4 behaves the same way. I only noticed this because I use embedded .tak files maintained by CUETools to store/port my CD collection.

Is this something I'm doing wrong, or a minor bug?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2013-05-30 04:16:43
Hope to see the new FLAC v1.3.0 being added to CUETools v2.1.5 before it gets officially released.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: arbingordon on 2013-05-31 01:59:46
Is there an archive of older versions of cuetools (and cueripper)?
2.1.4 and 2.1.5 fail to rip a number of CDs that rip flawlessly for me on EAC.
I'd just like to roll back to a version that works.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2013-05-31 02:04:19
It would be better for everyone involved if you could provide details about the problem and the affected CDs so that Gregory could attempt to fix the issue, thus saving you from having to miss out on newer features simply to avoid a problem that almost certainly is fixable.

I would recommend a source of older versions that can fill the gap until such time as Gregory can address the issue, but I am not aware whether or not such a thing exists.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-31 04:11:05
The make and model of the drive can also be helpful to Grigory.

http://www.cuetools.net/install/CUETools_2.1.1.rar (http://www.cuetools.net/install/CUETools_2.1.1.rar)
http://www.cuetools.net/install/CUETools_2.1.2a.rar (http://www.cuetools.net/install/CUETools_2.1.2a.rar)

These older versions are not fully compatible with the current CUETools DataBase.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-05-31 04:37:29
Samsung TSSTcorp CDDVDW SH-S203B drive
Tested with CUERipper 2.1.4 & 2.1.5 only
On extremely scuffed/scratched/dirty discs and some discs longer than 74 minutes, I get

(http://img96.imageshack.us/img96/5463/cr12.png)

some time after the Error Correction bar lights up. The rip aborts at this point and there are no log files written.
Cleaning/polishing the disc does prevent the exception on some.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mistermac on 2013-06-03 22:52:22
Sorry for offtop, but I need the source code for CUETools 1.9.5a very much!
Please, help me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-06-03 23:45:36
It's probably this, but why would you need a version so old?
https://sourceforge.net/p/cuetoolsnet/code/...04289fb/tarball (https://sourceforge.net/p/cuetoolsnet/code/ci/69b54bab5dc39f1ea765776a729236da204289fb/tarball)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mistermac on 2013-06-04 08:30:12
Looks like it, thank you.

Previously, source code of the  older versions could be easily downloaded from the first page. It was very convenient.
Let version is the old, but I'm satisfied with everything, especially with interface. There is just a pair of functions that I would like to add.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2013-06-07 15:56:08
Are there plans to make CUETools work with single-track albums? Currently, if I drag the track (of which the album consists), it gives me an error saying that I didn't input an album. In order to get around this, I have to create a dummy CUE sheet, which can be a bit of a hassle.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Rollin on 2013-06-07 17:10:00
Currently, if I drag the track (of which the album consists), it gives me an error saying that I didn't input an album. In order to get around this, I have to create a dummy CUE sheet, which can be a bit of a hassle.

You can drag m3u playlist
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-06-13 19:00:24
Is it not possible to browse through network shares with CUETools? I have my music library located in one and even though it's added into my music library, CUETools doesn't seem to see it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-06-14 06:09:04
Some other things I noticed:

- When transcoding to the same path as source files, it asks you if you want to overwrite, yet says source = dest is not possible if you confirm. Can't it transcode to a temp file, then rename it to overwrite the source as the prompt suggests is possible?

- When transcoding an album that has multiple track artists, CUETools insists on picking the first track artist as album artist in batch mode, messing up the tags. Suggestion: allow to customize that, for example set to predefined string/leave album artist empty/prompt on multiple track artists

- Is it possible to process ONLY the .cue files? As it is now, you have to go to each directory and explicitly tick only the .cue, else  which is rather cumbersome if you want to transcode your whole library. I tried looking into scripting, but there seems to be no documentation on the syntax/object properties

- Would be nice to have an option to ALWAYS save .cue as utf-8, looks like it didn't made into 2.1.5
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2013-06-14 22:15:33
Is it not possible to browse through network shares with CUETools?

I'm running CueTools in an XP Virtual Machine on Linux, with a Samba file server on another Linux box. I can browse/verify/repair over the network using an SMB share.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2013-06-14 22:20:03
- Would be nice to have an option to ALWAYS save .cue as utf-8, looks like it didn't made into 2.1.5

I agree completely, but from what I've deduced, if there are no Unicode chars in a file, then utf-8 == ASCII. There would have to be some kind of header/footer added using utf-8 only chars to actually make the file utf-8.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-06-20 15:06:23
Detailed log, CD-Extra data track bug

A bug-fix was made in 2.1.4 but it did not completely fix the issue in the log. This still wasn't fixed in 2.1.5.

disc without data track (partial log)
Code: [Select]
[CUETools log; Date: 6/20/2013 6:45:11 AM; Version: 2.1.5]
[CTDB TOCID: eAEwOGhXm4Xc9lIzrRUM__ZsbMo-] found.
        [ CTDBID ] Status
        [8e0dd717] (69/91) CD-Extra data track length 01:28:38, Accurately ripped
        [af00bb3f] (03/91) Accurately ripped
        [8e0dd717] (04/91) CD-Extra data track length 01:08:69, Accurately ripped
        [11936b70] (01/91) CD-Extra data track length 01:28:38, No match
        [d17bf126] (01/91) CD-Extra data track length 01:28:38, No match
        [8e0dd717] (02/91) CD-Extra data track length 01:30:38, Accurately ripped
        [a32d2d44] (01/91) CD-Extra data track length 01:28:38, No match
        ...
disc with data track (partial log)
Code: [Select]
[CUETools log; Date: 6/20/2013 6:43:53 AM; Version: 2.1.5]
CD-Extra data track length 01:28:38.
[CTDB TOCID: eAEwOGhXm4Xc9lIzrRUM__ZsbMo-] found.
        [ CTDBID ] Status
        [8e0dd717] (69/91) Accurately ripped
        [af00bb3f] (03/91) Has no data track, Accurately ripped
        [8e0dd717] (04/91) , Accurately ripped
        [11936b70] (01/91) No match
        [d17bf126] (01/91) No match
        [8e0dd717] (02/91) , Accurately ripped
        [a32d2d44] (01/91) No match
        ...
Note the missing alternate data track length info on a disc with data track.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-06-20 15:18:12
I'm running CueTools in an XP Virtual Machine on Linux, with a Samba file server on another Linux box. I can browse/verify/repair over the network using an SMB share.
For me on win7, the multiselect browser doesn't show any network entries, just computer and local db. If I mount the share as a drive it does list it, but I'd like to see it actually browse the whole network instead.

I agree completely, but from what I've deduced, if there are no Unicode chars in a file, then utf-8 == ASCII. There would have to be some kind of header/footer added using utf-8 only chars to actually make the file utf-8.
Actually, as Gregory said, currently it only saves the .cue in utf-8 if there are characters not in your codepage. So since I run this PC in Japanese locale, no .cue is saved in utf-8 for my music, making me convert it manually for other PCs I have.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-06-22 19:59:30
ive used cuetools for years and never had any problems. but all of a sudden its not working.

it cannot decode flac files. or any files. if i go into settings theres no decoders available to choose from anymore?

i redownloaded the program. tried the latest stable and latest dev build. ive cleared all settings. ive made sure all of the runtimes are installed. im at a loss here.. ive googled around for an answer and cant find anything.

im running windows 7 x64, and ive successfully used cuetools on this windows install, it just stopped working and has gotten this issues.

could someone please help me?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-06-22 23:39:39
ive cleared all settings

By that do you mean you deleted the settings file from
C:\Users\<your user name>\AppData\Roaming\CUE Tools\
(or deleted the whole folder) while CUETools wasn't running?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-06-23 03:09:59
ive cleared all settings

By that do you mean you deleted the settings file from
C:\Users\<your user name>\AppData\Roaming\CUE Tools\
(or deleted the whole folder) while CUETools wasn't running?

yes thats what it means
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-06-23 03:46:00
What's the latest change to your system before it stopped working? Any new antivirus software or service packs or anything like that by any chance?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-06-23 04:45:21
What's the latest change to your system before it stopped working? Any new antivirus software or service packs or anything like that by any chance?

nothing like that that i can remember. just normal software. its been a few months since i last used it so i cannot be totally sure. but in the case of anti virus, no. and nothing like a service pack.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-06-24 14:00:56
Bug report - CUETools 2.1.5 (12 June build)

Encode - Selecting wav for audio output gives unhandled exception:
System.NullReferenceException: Object reference not set to an instance of an object.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-06-24 17:24:13
2.1.5 Bug Report

- On repair Disc Number and Total Discs are not padded ( 1/2 and 2/2 vs 01/02 and 02/02) to match existing meta data

- After repairing a disc, I keep all the good tracks from a rip and just move the corrected track into the original directory, and then I re-verify. With 2.1.5, I cannot re-verify without the dummy cue. For some reason, after copying a repaired track to a directory to replace the bad track 2.1.5 can ONLY see the first 2 tracks, and then reports the disc is not in the database. And it always seems to be the first to track even though neither was repaired....
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fickoyanka on 2013-06-28 12:19:00
Hope to see the new Monkey's Audio Latest Version 4.12 (June 26, 2013)  being added to CUETools v2.1.5 before it gets officially released.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DarkMaru on 2013-06-28 14:19:04
Hello.
in 2.1.5 version history "FLACCL: hi-res audio support", but error "Exception: Audio format is not Red Book PCM." appear.
Please help to solve this. It happens with such file, that's when I try it recompress in FLAC...
------------------------------------------------------------------------------
Format                              : FLAC
Format/Info                        : Free Lossless Audio Codec
Duration                            : 2mn 26s
Bit rate mode                      : Variable
Bit rate                              : 1 485 Kbps
Channel(s)                          : 2 channels
Sampling rate                      : 48.0 KHz
Bit depth                            : 24 bits
Stream size                        : 25.9 MiB (100%)
Writing library                      : libFLAC 1.2.1 (UTC 2007-09-17)
------------------------------------------------------------------------------
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-06-28 14:40:28
You are probably using an old version, even if it's 2.1.5 - there have been several updates to 2.1.5. Download it again here: http://www.cuetools.net/install/CUETools_2.1.5.zip (http://www.cuetools.net/install/CUETools_2.1.5.zip)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-06-28 19:35:18
You are probably using an old version, even if it's 2.1.5 - there have been several updates to 2.1.5. Download it again here: http://www.cuetools.net/install/CUETools_2.1.5.zip (http://www.cuetools.net/install/CUETools_2.1.5.zip)


Pretty sure its the newest (installed in last 2 weeks), but will re-install and try again.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-06-29 00:37:26
FLACCL: hi-res audio support refers to the CUETools.FLACCL.cmd.exe command-line tool.

CUETools.exe still only accepts PCM (or lossless) Red Book audio input. You will still receive an "Exception: Audio format is not Red Book PCM" in CUETools if you try to input other than 16-bit, 44.1kHz stereo.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2013-06-29 01:20:42
How do I update to 2.1.5? Do I simply replace the files?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-06-29 01:38:29
The zip file contains a folder named CUETools_2.1.5

You can simply unzip to the same parent folder as the previous version and update any references or shortcuts you made for the previous version to the new folder name. You can run as you did the previous version unless you ran as a portable application, then you'll need to copy/paste the CUE Tools and CUERipper sub-folders from the previous version to the CUETools_2.1.5 folder and delete the user_profiles_enabled file from the CUETools_2.1.5 folder before you run.
Note that there are still a few minor bugs in 2.1.5 so you might want to keep the previous version (and folder) until 2.1.5 is stable.

You can (as you suggested) copy and replace the files in the previous version's folder if you prefer. If you run as a portable application make sure to delete the user_profiles_enabled file if it gets added back to the folder.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-06-29 13:00:54
You are probably using an old version, even if it's 2.1.5 - there have been several updates to 2.1.5. Download it again here: http://www.cuetools.net/install/CUETools_2.1.5.zip (http://www.cuetools.net/install/CUETools_2.1.5.zip)


Downloaded fresh last night. In repair mode, CT is stripping ALL track AND disc number padding now. So the original files meta-data has tracks 01,02,03, total tracks 09... and disc 01, total 01. CT strips the padding, so they are 1,2,3... total 9, disc 1, total 1...

In repair mode, CT to should copy everything exactly and only repair the audio stream.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2013-06-29 13:38:29
What about adding cross-pressing verification for AccurateRip v2
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Brian_OConner333 on 2013-07-03 14:43:48
Need help with newest version (2.1.5)
When I'm trying to convert file with FLACCL encoder, I get this message: "Exception: Build failed with error code BUILD_PROGRAM_FAILURE"
When I'm converting using libFLAC everything is fine. On previous version (2.1.4) FLACCL worked just fine.
What's the matter?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-03 14:46:08
Usually with BUILD_PROGRAM_FAILURE there should be a more detailed error message, a line of source code or something. No such luck?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Brian_OConner333 on 2013-07-03 14:48:33
Usually with BUILD_PROGRAM_FAILURE there should be a more detailed error message, a line of source code or something. No such luck?

no, nothing
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-03 14:56:50
What GPU are you using?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Brian_OConner333 on 2013-07-03 14:57:35
nvidia 9800GT
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: edwardar on 2013-07-03 15:15:47
Need help with newest version (2.1.5)
When I'm trying to convert file with FLACCL encoder, I get this message: "Exception: Build failed with error code BUILD_PROGRAM_FAILURE"
When I'm converting using libFLAC everything is fine. On previous version (2.1.4) FLACCL worked just fine.
What's the matter?

I have the same problem with my 8600GT, it works on a previous beta of 2.1.5 (downloaded in May) and on 2.1.4.  I get the same error message with no further detail.

EDIT: I updated to the latest nVidia drivers, but this made no difference.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-03 15:56:38
Ok, that's probably a known problem discussed here: http://www.hydrogenaudio.org/forums/index....st&p=838124 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=64628&view=findpost&p=838124)
In this case it will be fixed in the next 2.1.5 iteration.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Brian_OConner333 on 2013-07-03 16:14:43
In that case, where can I find previous 2.1.5 beta?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-03 16:37:28
I will probably update it in a few days.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jensend on 2013-07-03 16:51:18
When you convert files you ripped with CueRipper, the file selection dialog shows two items to convert in each folder: the .cue file and the collection of audio files themselves. Simply proceeding means that CueTools will encode everything twice and ask you whether you want to overwrite. Am I missing something, or is the only way to not do things twice to go through and manually deselect something in every folder?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-03 17:08:14
Assuming you're using 'Multiselect Browser' input mode (you didn't specify), select only the CUE file(s) instead of having CUETools process the whole folder (don't put a check in the folder(s)).

Edit: browser type
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-07-03 18:29:50
That's hardly practicable if you're trying to select a large set of files though, something like "process .cue only" option would be nice to have.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-05 14:40:24
I will probably update it in a few days.

Not sure why it wasn't announced but there is a new update
http://www.cuetools.net/install/CUETools_2.1.5.zip (http://www.cuetools.net/install/CUETools_2.1.5.zip)
that should fix a few 'critical' bugs that involved 'Exception' messages.
Other requests and minor bug fixes may be addressed in a future update. There is no need to 'bump' your requests at this time.

Looks like libFLAC was also updated to version 1.3.0 and some new hardware support for FLACCL.
See Changelog (http://www.cuetools.net/wiki/CUETools_Changelog) for more info.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-07-05 20:50:54
Just tested the newest 2.1.5, got an exception closing CUETools:
Code: [Select]
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
  at JDP.frmCUETools.SaveSettings()
  at System.Windows.Forms.Form.WmClose(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5466 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
CUETools
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5468 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
CUETools.Processor
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.Processor.DLL
----------------------------------------
CUETools.Codecs
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.Codecs.DLL
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
CUETools.CTDB
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.CTDB.DLL
----------------------------------------
CUETools.Compression
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.Compression.DLL
----------------------------------------
CUETools.Ripper
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.Ripper.DLL
----------------------------------------
CUETools.Codecs.APE
Assembly Version: 1.0.4933.39970
Win32 Version:
CodeBase: file:///D:/Program%20Files/CUETools/Plugins%20(x64)/CUETools.Codecs.APE.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
CUETools.Codecs.FLAC
Assembly Version: 1.5.0.0
Win32 Version:
CodeBase: file:///D:/Program%20Files/CUETools/Plugins%20(x64)/CUETools.Codecs.FLAC.dll
----------------------------------------
CUETools.Codecs.HDCD
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Program%20Files/CUETools/Plugins%20(x64)/CUETools.Codecs.HDCD.dll
----------------------------------------
CUETools.Codecs.LAME
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Program%20Files/CUETools/Plugins%20(x64)/CUETools.Codecs.LAME.dll
----------------------------------------
CUETools.Codecs.TTA
Assembly Version: 1.0.4933.39970
Win32 Version:
CodeBase: file:///D:/Program%20Files/CUETools/Plugins%20(x64)/CUETools.Codecs.TTA.dll
----------------------------------------
CUETools.Codecs.WavPack
Assembly Version: 1.2.0.0
Win32 Version:
CodeBase: file:///D:/Program%20Files/CUETools/Plugins%20(x64)/CUETools.Codecs.WavPack.dll
----------------------------------------
CUETools.Compression.Rar
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/Plugins%20(x64)/CUETools.Compression.Rar.dll
----------------------------------------
Bwg.Hardware
Assembly Version: 0.0.7.1
Win32 Version: 0.0.7.1
CodeBase: file:///D:/Program%20Files/CUETools/plugins/Bwg.Hardware.DLL
----------------------------------------
Bwg.Logging
Assembly Version: 0.0.7.1
Win32 Version: 0.0.7.1
CodeBase: file:///D:/Program%20Files/CUETools/plugins/Bwg.Logging.DLL
----------------------------------------
Bwg.Scsi
Assembly Version: 0.0.7.1
Win32 Version: 0.0.7.1
CodeBase: file:///D:/Program%20Files/CUETools/plugins/Bwg.Scsi.DLL
----------------------------------------
CUETools.Codecs.ALAC
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/plugins/CUETools.Codecs.ALAC.DLL
----------------------------------------
CUETools.Codecs.FLACCL
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/plugins/CUETools.Codecs.FLACCL.DLL
----------------------------------------
CUETools.Codecs.FLAKE
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/plugins/CUETools.Codecs.FLAKE.DLL
----------------------------------------
CUETools.Codecs.WMA
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/plugins/CUETools.Codecs.WMA.DLL
----------------------------------------
CUETools.Compression.Zip
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/plugins/CUETools.Compression.Zip.DLL
----------------------------------------
CUETools.Ripper.SCSI
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/plugins/CUETools.Ripper.SCSI.DLL
----------------------------------------
CUETools.CDImage
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.CDImage.DLL
----------------------------------------
ICSharpCode.SharpZipLib
Assembly Version: 0.85.5.452
Win32 Version: 0.85.5.452
CodeBase: file:///D:/Program%20Files/CUETools/plugins/ICSharpCode.SharpZipLib.DLL
----------------------------------------
OpenCLNet
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Program%20Files/CUETools/plugins/OpenCLNet.DLL
----------------------------------------
WindowsMediaLib
Assembly Version: 1.1.0.23204
Win32 Version: 1.1.0.23204
CodeBase: file:///D:/Program%20Files/CUETools/plugins/WindowsMediaLib.DLL
----------------------------------------
6oq6hbqq
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
te50tyyf
Assembly Version: 1.0.4933.39970
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
msvcm90
Assembly Version: 9.0.30729.6161
Win32 Version: 9.00.30729.6161
CodeBase: file:///C:/Windows/WinSxS/amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251/msvcm90.dll
----------------------------------------
l-assjk4
Assembly Version: 1.5.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
-i8f3dpc
Assembly Version: 1.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
kyxcywfq
Assembly Version: 1.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
2cgziuyt
Assembly Version: 1.0.4933.39970
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
qccjsjxl
Assembly Version: 1.2.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
lzcxqq3p
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
-jszqn-w
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
uxcsqipy
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
r3yagzb8
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
ui7jjavn
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
bguemp1v
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
agol2ljd
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
CUEControls
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUEControls.DLL
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
CUETools.AccurateRip
Assembly Version: 2.1.5.0
Win32 Version: 2.1.5.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.AccurateRip.DLL
----------------------------------------
lgksrzqf
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
w6uyiyzz
Assembly Version: 2.1.5.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
taglib-sharp
Assembly Version: 2.0.4.0
Win32 Version: 2.0.4.0
CodeBase: file:///D:/Program%20Files/CUETools/taglib-sharp.DLL
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
CUETools.Parity
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Program%20Files/CUETools/CUETools.Parity.DLL
----------------------------------------
ufymrm6i
Assembly Version: 1.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
Freedb
Assembly Version: 1.0.0.1
Win32 Version: 1.0.0.1
CodeBase: file:///D:/Program%20Files/CUETools/Freedb.DLL
----------------------------------------
klx3gtra
Assembly Version: 1.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
Only once though, maybe it has something to do with me having 2.1.4 config info previously
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Dario on 2013-07-05 20:53:53
A small remark - if the 'Offset' field is filled and I attempt to create a CUE sheet of the selected album (using the 'Create CUE Sheet' checkbox), I will get the 'Writing a non-zero offset...' warning, which I don't think has any meaning as far as CUE sheet creation goes. I am not encoding the tracks or anything.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Brian_OConner333 on 2013-07-06 17:17:55
New version didn't fix my problem, still getting that message
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2013-07-06 17:46:05
Here's an idea for a possible feature I want to share. It comes from an experience I recently encountered with a defective reissue.

The problematic CD has audible errors which must have been introduced during mastering it in the CD fab or maybe because a defective original pressing was used as a source or something like that. Yes, there exists an original pressing which is almost identical, apart from an offset and those corrupted sectors. And my reissue is present in both AR and CTDB and it verified fine, so these exact same defects must be present in other people's CDs, too.

Since the differences are only minimal (on most tracks affected) and may have been covered by Cue Tools' error correction, I'm wondering why not let the user mask a certain pressing as a different one if he likes, and let CUE Tools "repair" it as if it were that different pressing.

I tried to trick CUE Tools into believing the rip was the original pressing of which repair information is present in the CTDB by offsetting the audio. But I must have missed something, because CT still recognised it being the new pressing, just with an offset... maybe you can tell me how exactly does CUE Tools determine which pressing a set of files is, Gregory?

Of course, just like one can override the offset it would be really neat to override the pressing identifaction at will so that during verification the log is written as if it was another pressing and during repair the rip is repaired with the other set of recovery data.

With the "defective" CD what I ultimately did was buy an old used original copy and ripped that one. Bonus was that I could finally compare both of their audio tracks, it turns out that on the first track apart from an audible glitch there are even a few samples missing right after the glitch, cut out, so that both tracks would be out of sync for half a minute, then the same number of samples is reinserted in the audio stream, but it's simply a duplicate of the samples that come right before the insertion. I wonder if CUE Tools would be able to repair such a complex defect.

Anyway with such a feature, people can in rare cases where they have bought a reissue with minor mastering errors which is not repairable transform it into a different pressing.

Oh, and while I'm at it I have another idea:

Why not introduce a repair log? Something that gives some clues about which samples have been repaired and how the damaged samples have looked like (null samples, etc...) and maybe some other stuff.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2013-07-06 19:12:56
Stil no option to prevent the CUE COMMENT written to the tag.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-06 22:55:14
I tried to trick CUE Tools into believing the rip was the original pressing of which repair information is present in the CTDB by offsetting the audio. But I must have missed something, because CT still recognised it being the new pressing, just with an offset... maybe you can tell me how exactly does CUE Tools determine which pressing a set of files is, Gregory?

With AccurateRip, 'alternate pressing' usually means audio CDs that have the same TOC (all tracks start and end at the same positions) and have identical data throughout the CD but at a different offset (see wiki (http://wiki.hydrogenaudio.org/index.php?title=AccurateRip#Pressings)). CTDB uses an Offset-finding checksum, a small (16-byte) recovery record for a set of samples throughout the CD, which allows detection of the offset difference between the rip in database and your rip, even if your rip contains some errors (from this wiki (http://www.cuetools.net/wiki/CUETools_Database#What_information_does_the_database_contain_per_each_CD.3F)). Discs with the same TOC would fall under the same CTDB TOCID (any HTOA (disc pregap) and CD-Extra data track info is excluded from the TOCID calculation and is stored separately in the database). Discs under that TOCID with the same data (same CRC32 excluding some samples at the start and end of the disc to allow for offsets) fall under the same CTDBID. I'm paraphrasing most of this from the wiki (http://www.cuetools.net/wiki/CUETools_Database). So if there are no differences in data between the pressings (except the data offset) and all tracks start and end at the same positions, both would have the same TOCID and CTDBID in the CTDB.

So if your 'defective CD' is an alternate pressing of the 'old used original copy CD' then both will fall under the same TOCID (which can be seen if you enable the Detailed log (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced) in CUETools). Each disc would fall under a different CTDBID due to the glitch but the rest of the disc should match. If the remaining differences are small enough to be repaired by the recovery record under the 'old used original copy CD' CTDBID you should see 'Differs in xxx samples' listed for that CTDBID when you verify the 'defective CD'. If it says 'No match' then too many samples differ to use the recovery record and you're out of luck.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 2013-07-07 14:04:13
Dang, I didn't realize CUE Tools has a wiki! I will check that information there against the two CDs and see how great the differences are.

So you are saying if the two pressings are close enough to be repaired then they would have been identified as the same pressing anyway by CUE Tools? Or did I not understand it correctly?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-07 15:43:38
Yes, identified as the same in the CUETools database (CTDB) with possible errors. However, if both the 'original' and 'glitched' discs are in the database with good quality under their respective CTDBIDs, then verifying one disc could show a match for one CTDBID and 'Differs in' for the other. Verifying the other disc would give similar results but flipping CTDBIDs.

Your rip log and AccurateRip can help to identify your rip so you don't repair when it isn't necessary.

Edit: Changed confidence to quality. A good quality rip (no errors) is normally needed for a recovery record to be in the database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-07-08 01:06:27
With the latest CueTools 2.1.5 I am still having a lot of problems with the following scenario:

Rip CD with some errors (ripping w/ dBpoweramp)
Repair with CueTools
Copy only the repaired tracks back to the original album
- fix the padding on disc and track numbers (typically use foobar for this)
Attempt to re-verify with CueTools.

The last step is where things go wrong. Before CT was consistently seeing only the first 2 tracks in an album folder in the above scenario. Now it doesn't see any audio files in the folder...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-08 01:08:19
Can you play around with tags on those files? For example, removing CDTOC tags, etc.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-08 02:35:17
New version didn't fix my problem, still getting that message

Could you please try the command-line FLACCL encoder? For example like this:
CUETools.FLACCL.cmd.exe somefile.wav -o nul

It will fail the same way, but it should show a more detailed error message that can help me identify the problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Brian_OConner333 on 2013-07-08 09:59:02
I'm getting this in commandline
(http://i47.fastpic.ru/thumb/2013/0708/09/a722e42d9a2890430560835ffc8fe009.jpeg) (http://fastpic.ru/view/47/2013/0708/a722e42d9a2890430560835ffc8fe009.jpg.html)
I guess. that there may be a problem with my GPU, because few days ago i found out that I can't play games anymore (it simply freezes). So if nobody with 9800GT or lower has the same problem, than the problem is in my GPU.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-08 12:48:50
Thanks. I don't think that your GPU is the problem, i just used couple of features that are probably not supported by it. I thought they were.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-07-08 13:21:01
My older PC with a 8600m GT exits with the same error message, so that's probably it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-07-09 20:19:59
I'm posting on behalf of a friend who says CUERipper 2.1.5 (current) crashed on him (Exception dialog) when ripping the last track of a particular 74-minute bootleg CD. After the exception, the drive was no longer recognized by the OS, but it came back after a reboot.

Exception: Error reading CD: IoctlFailed
Drive: HL-DT-ST DVD-ROM GDRH20N 0L02
OS: Win7 64-bit

That's about all I have to go on. A bit of Googling reveals that the DVD-R version of this drive is known to have the same kind of problem on the last track when burning, but my friend's drive is read-only, and I don't see anything about problems when reading. Let me know if I need to have him try anything different or gather more info.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-14 18:36:50
Hello, I've been using CUETools for a couple of years, and now I'm using the 2.1.4 version.

I noticed that CUETools looks for the log file of a given rip, when I want to verify it through accuraterip, asking me to select it.

Some log files have been produced by ripping a CD with a read offset equal to zero (or a wrong non-zero one in rare cases), so everytime I have to look to the accuraterip drive offset page to manually find the read offset of the drive used in the ripping process.

My question is, would it be possible to add a function that, when someone wants to verify a rip, does the following?:

1) it searches for the log
2) it ask the user to select the log
3) it identifies the drive used
4) it looks in the accuraterip drive offset database
5) it asks the user if he wish to apply the correct offset
6) it eventually sets the offset, if the user has decided to do so

I wanted to suggest this because in my opinion it would be a great time saver.

This would be nice for the following modes of CUETools:
- Encode
- Verify
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2013-07-14 19:05:02
How many drives did you use to make those rips? 

(Hint: CUETools is meant to be a tool for veryfing your own rips  and that should be its development focus)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2013-07-14 19:07:36
If you're that fucking anal about your music, buy the CD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-14 22:43:27
@greynol

Fortunately I've bought enough CDs to make my own rips and proper considerations. On the other hand, it would be extremely difficult for me to follow your fine suggestion in some special cases of mine, but I appreciate your interest, anyway.

@Goratrix

Here is my suggestion: if someone is unfamilar with EAC and uses a wrong read offset during the ripping process, I think that it would be a good idea for CUETools to detect the log file (it already does that), to analyze the read offset used, and to finally provide the correct read offset to the user. I think it could be done by using some regular expressions / parsing on the log file, and querying the accuraterip read offset database (like it happens on EAC + AccurateRip).

A strong point of CUERipper should be that it greatly simplifies the process of ripping a CD (skipping the long EAC configuration), so CUETools could do something similar, by suggesting the inexperienced user the correct value for the offset, before verifying or encoding the audio tracks through CUETools, by analyzing the already existing log file.

It would be interesting to hear Gregory impressions, to verify it technical feasibility. In my humble opinion, it would be a feature appreciated by many.

In any cases, I'm anxious to try the new 2.1.5 version once it gets stable, I'm sure that many improvements will be made!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2013-07-14 22:59:29
The reference used by EAC and adopted by AccurateRip is hardly as sacrosanct as you appear to believe it to be.

If I use something different, who are you to say that I am not correct in doing so?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-14 23:15:50
I suppose you are referring to the read offset - drive association?

In that case, no one could know the answer, like you're correctly stating. Thus, the probability to have some mismatches, is unfortunately different than zero, so it could probably happens.

But statistically, there is a huge difference. Let's consider a real case: I analyzed more than 500 CD with CUETools, some with correct offset and some not, but in each case there haven't been any mismatch, once I set the correct drive read offset.

You are right, there could be some special cases of mismatch... but even 1% of the total cases, in my opinion is negligible.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2013-07-15 01:46:22
That's not at all what I was getting at, but whatever. Gregory Chudov knows what I'm talking about which is all that matters. If he implements your suggestion I will still hold you responsible for any misinformation that may result.

So that you may know, none of the entries to which you are referring as having the "correct offset" actually have the correct offset because the reference wasn't properly determined.

Don't take this as an endorsement for the true offset, rather I'm poking fun at those who think their ill-gotten music is somehow better if it is calibrated to an arbitrary reference.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-07-15 11:35:21
I don't even understand what Pidgeon wants to be honest. Even if the cd was ripped with a wrong offset, cuetools will still be able to verify if it was ripped correctly (offsetted by xxx). And from what I remember, Gregory said that using the "fix offset" (so that no offset has to be applied when verifying) shouldn't be used unless the offset is horribly wrong, e.g. audibly wrong transition between tracks etc.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-15 14:00:30
That's not at all what I was getting at, but whatever. Gregory Chudov knows what I'm talking about which is all that matters. If he implements your suggestion I will still hold you responsible for any misinformation that may result.

So that you may know, none of the entries to which you are referring as having the "correct offset" actually have the correct offset because the reference wasn't properly determined.

Don't take this as an endorsement for the true offset, rather I'm poking fun at those who think their ill-gotten music is somehow better if it is calibrated to an arbitrary reference.


Rather I was laughing at the "If he implements your suggestion I will still hold you responsible for any misinformation that may result" part. Do you think that I could be the cause of the world to collapse? Or this is what have been prophesied by the Mayan civilization? Well, some of the ideas you have might sounds right, but you are taking this way too seriously, and I don't need a personal judge who tell me of which things I'm responsible and which not, I think to be old enough to take my own responsibilities. After having clarified this, remember that everything started from a simple suggestion. Good or bad it was, this yet has to be seen.

Then, again, you are contradicting yourself: you are stating that Gregory knows what you are talking about about, and this is all that matters, which I think is great because he's the developer of CUETools, and not me or you. Afterwards, you state that I would be responsible if he implements my suggestion. But you just made a fine paradox, how could he implements my (wrong?) suggestion if he would know your (right?) reasons? We have two options:
a) Gregory doesn't know what you're talking about (but you suggested that this is not the case).
b) You think that Gregory could implement my suggestion, and its consequences "concern" you. I used the term "concern" because by your aggressive attitude, it seems that the consequences of my suggestion would be scaring for whatever reason, but I repeat mine was only is a simple suggestion for an already great software, I don't want to scare anyone.

You finally stated:
"Gregory Chudov knows what I'm talking about which is all that matters."
So I ask you with humility to enlighten me and the other users about the possible (technical) consequences that my simple suggestion could lead to, so that we could happily learn something about it.

Regarding the "ill-gotten music", this is your own assumption: you have no power to judge if, when, why or how I should own the music of my library. You don't know the story behind it, and you'll never be. Thus, please keep those unnecessary and accusatory assumptions for yourself.

Gregory said that using the "fix offset" (so that no offset has to be applied when verifying) shouldn't be used unless the offset is horribly wrong, e.g. audibly wrong transition between tracks etc.


This is interesting, is there a particular reason for that? Anyway, I suppose you are talking about the "encoding" process, where you can decide if to fix the offset or not. So, my suggestion could be valid for the "verification" process, which consists on verifying the rip against the AccurateRip database and calculating the CRC for each track. In that case, in my opinion it would be a nice addition to know the correct drive read offset before starting the process, obtainable if the log file reports the drive used for the audio extraction. For what I know, by doing that, there would be problems only in the following cases:
- I rip a CD, then I manually modify the resulting log by changing the name of the drive I used in the ripping process.
- I rip a CD, then I grab a different log elsewhere, replacing the original one.
In these cases, CUETools would report a wrong read offset. Statistically, this won't likely happen, and anyway which are the reasons why someone would want to do so?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2013-07-15 14:10:33
d125q suggested using tak_deco_lib.dll instead of piping the decode output of takc here (http://www.hydrogenaudio.org/forums/index.php?showtopic=101386&view=findpost&p=838458), to work around TAK's inability to handle unicode paths/filenames. Any chance of this happening?

edit: also, can we have an option to use a temporary file for encoding similar how foobar2000 does it? It creates a random ASCII named .wav first, which is then passed to the encoder, then renames the output file correctly once the conversion is finished. Again, a workaround for TAK's unicode problems =/

This is interesting, is there a particular reason for that?
From what I remember, a simple "never touch a running system". Maybe something might go wrong when fixing the offset, so it's reserved for cases where something already gone wrong. A "wrong" offset rarely matters anyway, so as long as CTDB/AR says it could match the rip, it's accurate.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-15 14:26:36
So, my suggestion could be valid for the "verification" process, which consists on verifying the rip against the AccurateRip database

See Post [a href='index.php?act=findpost&pid=642349']#444[/a], [a href='index.php?act=findpost&pid=711430']#1078[/a] & [a href='index.php?act=findpost&pid=765329']#1500[/a]. I might be able to find more but you can search for yourself.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2013-07-15 14:43:04
If he implements your suggestion I will still hold you responsible for any misinformation that may result.

I've given this gentleman too much credit while not giving enough credit to Gregory.  My apologies.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-15 14:54:53
So, my suggestion could be valid for the "verification" process, which consists on verifying the rip against the AccurateRip database

See Post [a href='index.php?act=findpost&pid=642349']#444[/a], [a href='index.php?act=findpost&pid=711430']#1078[/a] & [a href='index.php?act=findpost&pid=765329']#1500[/a]. I might be able to find more but you can search for yourself.


Yours is a truly informative post, I'm thankful to you. I'll surely give those post a thorough reading!

I'll wait for Gregory impressions, as I'm curious to hear what the developer thinks about my suggestion, in particular regarding the read offset identification before the beginning of the "verify" process. If he finds it to be an uninteresting thing to add, great, if he finds it to be a good idea, great! In any case, I'll keep using this great software like I did in the previous years, and I'll continue to spread the word about it!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Eli on 2013-07-15 16:46:44
Can you play around with tags on those files? For example, removing CDTOC tags, etc.


I have not systematically gone through to figure out exactly what tags may be causing the problems. However, as long as I edit the tags with dBpoweramp and put the padding on both tracks and disc numbers, things seem to be working.

For some reason, CT is no longer copying the track # tags at all, track # or track total.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-15 18:41:10
in particular regarding the read offset identification before the beginning of the "verify" process.


There's currently only one reason for verify process to care about offset, and that is for ARv2 verification. ARv1 and CTDB verification does not need to know anything about the offset.

The only idea i had about cross-pressing ARv2 verification was a two-pass process - one pass to figure out the offsets, one pass to calculate ARv2 CRCs for each offset found in pass one.

In one-pass mode we can use offset from the log, but there might be better ways to do this. AR has a special offset correction CRC for one sector for each track, specifically for that purpose. I haven't been really using it up until now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2013-07-16 08:13:29
Need help with newest version (2.1.5)
When I'm trying to convert file with FLACCL encoder, I get this message: "Exception: Build failed with error code BUILD_PROGRAM_FAILURE"
When I'm converting using libFLAC everything is fine. On previous version (2.1.4) FLACCL worked just fine.
What's the matter?

I have the same problem with my 8600GT, it works on a previous beta of 2.1.5 (downloaded in May) and on 2.1.4.  I get the same error message with no further detail.

EDIT: I updated to the latest nVidia drivers, but this made no difference.

Got the same error with my 8800GTX today: http://i.imgur.com/dU1bk0B.png (http://i.imgur.com/dU1bk0B.png) (CUETools 2.1.5, archive dated July 5th)

The "Device"-line says OpenCL 1.1, but according to nVidia-docs, my card is well below the necessary specs for 1.1 (Compute Capability >=2.0), according to this post (https://devtalk.nvidia.com/default/topic/499998/cuda-programming-and-performance/opencl-v1-1-support-in-latest-drivers-new-drivers-with-opencl-v1-1-support/post/3572053/#3572053) at the nvidia-forum and this nvidia-doc (https://developer.nvidia.com/cuda-gpus). If I read this document correctly, pretty much everything below 4xx doesn't support 1.1.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2013-07-16 10:49:16
As a follow-up:
On a laptop with a 310M (also not OpenCL1.1-compatible, Compute Capability (CC) (http://en.wikipedia.org/wiki/CUDA#Version_features_and_specifications) 1.2), the program is encoding fine. The CC-level of the 8800GTX is 1.0.
The program "GPU Caps Viewer (http://www.geeks3d.com/20130618/gpu-caps-viewer-1-18-1-videocard-information-utility-opengl-opencl-geforce-radeon-gpu/)" shows the supported OpenCL- and CC-level.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-16 14:47:18
in particular regarding the read offset identification before the beginning of the "verify" process.


There's currently only one reason for verify process to care about offset, and that is for ARv2 verification. ARv1 and CTDB verification does not need to know anything about the offset.

The only idea i had about cross-pressing ARv2 verification was a two-pass process - one pass to figure out the offsets, one pass to calculate ARv2 CRCs for each offset found in pass one.

In one-pass mode we can use offset from the log, but there might be better ways to do this. AR has a special offset correction CRC for one sector for each track, specifically for that purpose. I haven't been really using it up until now.


This is intriguing, thanks for having shared your thoughts!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ClashRocker on 2013-07-21 13:58:50
Hi, is there a way to totally disable AccurateRip system?  I know that may sound like a strange request, but let me explain.

I use CueRipper because it's a really good ripping program, but I don't care too much about accurate ripping, having it take 30 minutes to rip a disk and have it complain about not finding a match is a major hassle to me.

I just want it to rip like other programs do, blind and not care.  I know the primary focus of CueTools is accurate ripping, and I know people here are very passionate about this, and that's all fine, but it would be nice to have the tool work in a less anal way.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Rollin on 2013-07-21 14:20:36
Disabling Accuraterip will not increase ripping speed.
If you need speed - use Burst mode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-23 21:34:49
I want to report a possible bug of the 2.1.4 version (I just tested the 2.1.5 version, and it seems to be bugged to).

Some days ago I used the offset correction function, but now this option seems to be suddenly grayed out as you can see here:

http://pasteboard.co/1jbvkCCl.png (http://pasteboard.co/1jbvkCCl.png)

This is not happening on my XP SP3 machine, instead the bug occurs on a Windows 7 Pro Edition x64 notebook.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2013-07-23 21:47:48
Hi, and thanks (again) for CueTools. A treat.

I'm wondering if there's been any improvement regarding Wavpack Hybrid (.wv+.wvc) with CueTools 2.x.
If I remember correctly, the developer mentioned how it was not implemented (implementable?) due to a lack of support for two files being generated simultaneously. However could not locate that message - not sure if it was on this very forum either.

Worst case solution, thanks to the last update of Wavpack it is now possible to do direct WV to WV+WVC conversion, following initial conversion/rip to plain WV. But it means: twice the time, twice the CPU usage & heat, twice the electric bill... 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-23 22:13:36
Some days ago I used the offset correction function, but now this option seems to be suddenly grayed out
This is not happening on my XP SP3 machine, instead the bug occurs on a Windows 7 Pro Edition x64 notebook.

Did you change the Windows screen text size since you last used it? CUETools has been reported to have a problem when changing screen text size in Windows 7 x64. Mine looks similar to this bug report (http://sourceforge.net/p/cuetoolsnet/bugs/10/) when screen text is re-sized to Medium - 125%.

I'm wondering if there's been any improvement regarding Wavpack Hybrid (.wv+.wvc) with CueTools 2.x.

See [a href='index.php?act=findpost&pid=822762']this post[/a] and [a href='index.php?act=findpost&pid=822785']my reply[/a]. Parameters can also be written -hb%Mxcm - %O
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2013-07-23 22:14:59
I’m not an expert on file I/O and have precious little patience for it in my own programming, but I can’t imagine why it would be a problem that the encoder writes two files concurrently. Doesn’t CUETools just have to pass the uncompressed stream to the encoder and forget about it? If not, I’d be interested in an explanation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2013-07-23 22:45:47
Some days ago I used the offset correction function, but now this option seems to be suddenly grayed out
This is not happening on my XP SP3 machine, instead the bug occurs on a Windows 7 Pro Edition x64 notebook.

Did you change the Windows screen text size since you last used it? CUETools has been reported to have a problem when changing screen text size in Windows 7 x64. Mine looks similar to this bug report (http://sourceforge.net/p/cuetoolsnet/bugs/10/) when screen text is re-sized to Medium - 125%.


Yes I've the same problem, unfortunately I must set the windows zoom to 138% because I'm using a full HD monitor, and I noticed that I can't resize the window because it appears to be locked. Hopefully this annoying bug will be fixed .
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2013-07-23 22:56:35
Thanks korth. Had completely overlooked your kind reply  better late than sorry

edit: nope, still hangs (at 0%, with wavpack.exe process at 0% CPU, have to kill it manually)

edit2: same issue with or without hybrid switches: wavpack.exe hanging at 0%. Tested with CT 2.1.4 and 2.1.5. (No issue at all with internal libwavpack, so my Cuetools install seems ok)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-24 00:20:37
Just tested on xp64 and win7x64 with latest 2.1.5 and wavpack 4.60.1
using -hb%Mxcm - %O with 320 selected on slider.
image+embedded, image+cue and tracks all encoded fine .wv+.wvc

There is a problem with the same track artist being used on all tracks in the embedded cue but that's another matter and does the same using libwavpack.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-24 05:04:02
Edit: Latest CUETools 2.1.5
Not sure how to explain the embedded cue/tag problem. I'm pretty sure I read something similar somewhere else but I can't find that post. Tested on flac, wv, & ape. ALBUM ARTIST tag is Various Artists and though the embedded cue appears to be correct, foobar2000 displays the same track artist (the one for track 1) for all remaining tracks.

Embedded cue

Quote
REM DISCID 8C0ADD0C
PERFORMER "Various Artists"
TITLE "Footloose"
CATALOG 0075678825477
REM DATE 2011
REM GENRE "Soundtrack"
REM COMMENT "CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov"
FILE "Various Artists - Footloose.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Blake Shelton"
    TITLE "Footloose"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PERFORMER "Zac Brown"
    TITLE "Where the River Goes"
    INDEX 01 03:39:52
  TRACK 03 AUDIO
    PERFORMER "Lissie"
    TITLE "Little Lovin'"
    INDEX 01 07:19:02
  TRACK 04 AUDIO
    PERFORMER "Ella Mae Bowen"
    TITLE "Holding Out for a Hero"
    INDEX 01 11:49:26
  TRACK 05 AUDIO
    PERFORMER "Jana Kramer"
    TITLE "Let's Hear It for the Boy"
    INDEX 01 17:11:08
...

foobar2000 Embedded Cue Sheet Editor shows

Quote
REM GENRE Soundtrack
REM DATE 2011
REM DISCID 8C0ADD0C
REM COMMENT CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov
CATALOG 0075678825477
PERFORMER "Various Artists"
TITLE "Footloose"
FILE "Various Artists - Footloose.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Footloose"
    PERFORMER "Blake Shelton"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Where the River Goes"
    PERFORMER "Blake Shelton"
    INDEX 01 03:39:52
  TRACK 03 AUDIO
    TITLE "Little Lovin'"
    PERFORMER "Blake Shelton"
    INDEX 01 07:19:02
  TRACK 04 AUDIO
    TITLE "Holding Out for a Hero"
    PERFORMER "Blake Shelton"
    INDEX 01 11:49:26
  TRACK 05 AUDIO
    TITLE "Let's Hear It for the Boy"
    PERFORMER "Blake Shelton"
    INDEX 01 17:11:08
...

Because much of the flac header can be read as text I can see that an Artist tag is being added to the file along with the embedded cue.

Quote
...CUE_TRACK08_CTDBTRACKCONFIDENCE=14/14%...CUE_TRACK09_CTDBTRACKCONFIDENCE=14/14%...CUE_TRACK10_CTDBTRACKCONFIDENCE=14/14%...CUE_TRACK11_CTDBTRACKCONFIDENCE=14/14%...CUE_TRACK12_CTDBTRACKCONFIDENCE=14/14....ALBUM=Footloose....ALBUMARTIST=Various Artists....GENRE=Soundtrack....DATE=2011=...COMMENT=CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov....ARTIST=Blake Shelton..

which is probably why foobar2000 is picking up Blake Shelton as the Artist for all tracks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: HotShotFR on 2013-07-24 11:51:47
Just tested on xp64 and win7x64 with latest 2.1.5 and wavpack 4.60.1
using -hb%Mxcm - %O with 320 selected on slider.
image+embedded, image+cue and tracks all encoded fine .wv+.wvc

There is a problem with the same track artist being used on all tracks in the embedded cue but that's another matter and does the same using libwavpack.


Tested on W8x64 with CUETools 2.1.5 and Wavpack 4.60.1, using the settings you mention: it works for Image+Cue and for Tracks, but not for Image+Embedded (hanging forever at 0%).
Have to reinstall my system today (new hardware incoming), will report if it works any better on a fresh install...

(Also confirming the bug you describe with the "Various Artists" files, whereby the many different track artists all get replaced by the Artist for track 1. Removing the "ARTIST" tag with metaflac for these Various Artists albums fixes the issue. Very annoying, it messed up many of my carefully-tagged rips for I noticed the issue too late, after processing files through Foobar's RG scanner - which screwed them definitively...)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-07-26 04:56:45
HDCD detection seems to be broken in CUETools 2.1.5. Enabling detection and 24bit-encoding, any input is 24bit-encoded, even if it is no HDCD.

Two years ago, someone stated the following in another forum: "... The 2.1.1 release of CUETools broke the HDCD detection. 2.1.2 was just recently released and I haven't yet tried it to see if it fixed the HDCD detection. I've been staying at 2.0.9 for now. ..." Is this feature actually broken for two years now and will it ever be fixed?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-26 05:06:54
I think it has always been so. You always have to start with 24-bit file, because HDCD markers don't have to kick in from the first frame, and they often don't. I could abort the encoding if no HDCD markers were detected after say 10 seconds i guess.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-07-26 05:26:55
I think it has always been so. You always have to start with 24-bit file, because HDCD markers don't have to kick in from the first frame, and they often don't. I could abort the encoding if no HDCD markers were detected after say 10 seconds i guess.


Thanks for the quick reply! I'd expect such an option to analyze the complete input first and then encode it with 16 bit (if no HDCD-encoded data was found) or with 24 bit (if HDCD-encoded data was found). Also, if all the input is always encoded 24 bit, how can I find out if the input was actually HDCD-encoded or not? I haven't found anything in the logs regarding this. Unfortunately the same goes for CUERipper: Even with setting "Detailed log" to "True", it nowhere tells me if an ripped CD was an HDCD.

In general it would be nice to have a "detect HDCD" option in CUERipper as well as in CUETools, with corresponding entries in the log files, if any HDCD data was found.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-07-26 17:26:45
sorry to bother you guys again. maybe a picture will help describe the problem im having.

(http://i.imgur.com/nb4oczG.png)

a fresh copy with the settings file not even existing gives me these settings. almost all of the encoders and decoders are missing.

is there anything i can try to remedy this? ill take any crazy ideas. anything. please help!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-26 17:32:35
Are you running it from a network share or something like that?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-07-26 17:35:55
nope. this one right here was running from my local desktop folder.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-26 18:43:25
I wonder if this is could be a damaged Windows user profile. Have you tried running it as a portable app? (Delete user_profiles_enabled from CUETools folder. Make sure CUETools folder isn't in Program Files folder.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-07-26 18:46:57
Or maybe you unzipped it without subfolders. CUETools looks for it's codec plugins in "Plugins" and "Plugins (x64)" subdirectories.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-07-26 18:55:45
nope and nope. tried it portable, and also have the folders intact.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-07-29 20:53:43
any other ideas i can try? any way to debug this problem? ill try anything!

thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2013-07-29 21:15:48
Do you have Microsoft .NET Framework 2.0 (SP2) and Visual C++ 2008 runtime properly installed like the CUEtools Wiki tells?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evil-doer on 2013-07-30 01:46:05
Do you have Microsoft .NET Framework 2.0 (SP2) and Visual C++ 2008 runtime properly installed like the CUEtools Wiki tells?

yes, and the rest of the system is as up to date as physically possible as well.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-31 18:01:27
OK I see a similar problem on my WinXPx64 system but I just have no WMA encoders. All files are present and hashes match the ones on my Win7x64 system (which has the WMA encoders). Don't know if these stopped working or never worked on the WinXPx64 system. evil-doer, if I find anything useful I'll let you know.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ligerpants on 2013-07-31 20:54:42
Bug report for 2.1.5 CUETools. The %date% template tag shows up literally in the end filename when encoding:

Helium - Pirate Prude (US %date%).tak

It worked in 2.1.4 and earlier. I haven't found any other tags that do this, but I haven't tested any I don't normally use:

%artist%  %releasetype%  %album%  %releasecountry%  %date%

--

EDIT: Also, in the resulting files, the Date tag is truncated from eg. 1994-03-08 to simply 1994.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-07-31 21:55:51
Try %year% for the album Date and %releasedate% for the Release Date
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: msmucr on 2013-07-31 23:45:46
Hello,

do you know, if there is any technical reason to not support audio formats other than 44100Hz/16bit in CUETools operations? I searched little bit about that, but found only one older post about that ( http://www.hydrogenaudio.org/forums/index....showtopic=92011 (http://www.hydrogenaudio.org/forums/index.php?showtopic=92011) ). Personally, i would be very happy, if it will be supported, mainly due to PS3 rips from SACD edited masters, but also for other general use with Hires files (for instance personally if i need to split something to tracks, it is very easy to write cuesheet). I know, that there are few other possibilities how to handle it, like in foobar or using commandline cuetools and shnsplit, but none is so comfortable (requires additional manual steps) and solid as CUETools.
Higher sample rates and 24bit quantisation should be supported by most lossless codecs. Lossy codecs usually working up to 48kHz, but for instance qaac comes with built-in sample rate converter.. So it is not completely covered to all output formats, but with this on mind, i'm not aware of other limitations.

Aside from this.. anybody else, who will welcome this functionality?

Best regards

Michal
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: db1989 on 2013-07-31 23:55:20
There is a technical reason in the sense that cuesheets were designed to specify the layout of audio CDs, and audio CDs are always sampled at 44100 Hz and in 16 bits.

Not completely sure, but I seem to recall that Gregory is on the record as saying this limitation is perfectly intended and will remain.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ligerpants on 2013-08-01 05:05:44
Try %year% for the album Date and %releasedate% for the Release Date


Thanks for the suggestion. On testing, these both also truncate to four digits, and only resolve if I choose Musicbrainz data instead of the cuesheet. Which is odd, because I use embedded cues, and tag with MB data using MB Picard (before embedding) and FB2K both. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: msmucr on 2013-08-02 00:52:39
There is a technical reason in the sense that cuesheets were designed to specify the layout of audio CDs, and audio CDs are always sampled at 44100 Hz and in 16 bits.

Not completely sure, but I seem to recall that Gregory is on the record as saying this limitation is perfectly intended and will remain.


Thanks for comment DB,

you're true about original purpose of cuesheets. I was just curious about that, as it evolved to me and could be used also for other things... and i have still preference for using cuesheet to lets say Matroska, despite it limitations (like 1/75s time step).

Best regards

Michal
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-08-04 01:41:16
Bug Report CUETools Version 2.1.5:

CUETools has a  problem with quotes used in the title of an album.

Ripping a CD with CUERipper and using an album title like

Vintage Gold [3"-CD]

this CD can be ripped and verified with CT/AR databases without any problem.

However, using CUETools for verifying this rip again, doesn't work, because of an "illegal character in path" error.
This is due to the ", used in the album title. I had to remove the " from the album title tags of all tracks to be able
to verify the rip.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-08-04 18:27:41
It's nice to have the "Preserve HTOA" option in CUERipper, but unfortunately the resulting file (FLAC, in my case) is free from any tags or an embedded artwork.
Is there a reason for this? All tags applying to the regular album tracks, usually also apply to potential HTOA (artwork included), so default behavior should be to include this stuff. I really can't imagine anyone caring about tags/artwork, but leaving a ripped HTOA track completely untagged ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: somian on 2013-08-18 05:49:50
Hello - and  for CUETools -

To try what I describe 3 paragraphs down:

I downloaded the testing / devel  http://www.cuetools.net/install/ (http://www.cuetools.net/install/)  ..... CUETools_2.1.5.zip

I run a distro closely tracking Ubuntu 13 with pretty new mono binaries.

I am switching to using Linux. I want to run CUETools on Linux platforms. On several different occasions I have read that CUETools via mono (or Wine, also?) does only support WAVE. I have rips made with CUETools on a Windows system which I have put into the Linux filesystem. These "rips" are done as single flac + separate CUE file. IOW, the source material for convert operations is a flac file with every track in one file, and cue file indexing into the flac file.

Can I use CUETools to convert these "rips" to anything - using mono to run CUETools on GNU/Linux

If not, can I use Wine to get the functionality to convert these "rips" to separate per-track .flac files? 

If none of the above, because no changes have been made in the situation since the last time a forum user reported anything about using mono to run CUETools ...then thanks for reading, and I did not mean to add noise to the forum, and thanks for all the work that goes into CUETools, and thanks for welcoming me to hydrogenaudio.

  somian
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-08-31 13:40:12
Bug Report CUETools Version 2.1.5:

CUERipper has a problem with "Barcode" tag and "CATALOG" entry in the CUE sheet.

When ripping a CD and entering a value for the "Barcode" tag, this info should be transferred to
the CUE sheet as "CATALOG" entry. However, this doesn't work. Most of the time the "CATALOG"
entry in the CUE sheet will contain some number (supposedly from freedb or a similar source),
but NOT the number that was manually entered under "Barcode".

In addition, besides the LABELNO, the barcode is an important identifier, that is very handy
when trying to exactly identify a release at sites like discogs. If you provide the possibilty to
enter this value during the ripping process, it would be only logical to also store this info in
a tag, and not only in the CUE sheet. Vorbis, for example, provides the generally accepted
EAN/UPN tag for this purpose.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-08-31 13:54:14
I think it's silently overwritten by a barcode that's read from the CD during gap detection - the cue should reflect the actual CD medium after all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-08-31 14:36:46
Slight chance the Barcode entry could revert back to what was retrieved from the db due to this bug

CUERipper currently saves metadata edits only when you start ripping, and reloads it only if the system reports that a drive (not necessarily the currently selected drive) has had a disc ejected or loaded. I don't know what might cause the OS to report this erroneously (never happened to me), but i should probably make CUERipper save metadata when this happens.

I recently experienced this on one disc (and only one disc) using the current 2.1.5 release. The metadata just kept reloading though nothing was happening with the drive. Unfortunately I didn't make a note of which disc it was and I haven't seen this happen since so I can't reproduce it.

Of course if the Barcode field was blank before the manual entry, the 'other number' isn't coming from the retrieved metadata.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-08-31 14:39:12
I think it's silently overwritten by a barcode that's read from the CD during gap detection - the cue should reflect the actual CD medium after all.


Shouldn't this decision be left to the user? Most of the time, the only barcode that is of any actual meaning, is the one that is printed on the package and serves the purpose to uniquely identify a specific RELEASE of an album (not disc). Using some kind of "secret" barcode (that many users won't even be able to read) in order to identify a DISC (as part of a release), isn't common practice, as usually matrix/runout information is used at this level of identification (which makes perfect sense, as only this information provides a reliable method for identifiying a disc, while the stored barcode doesn't).

I think you'll agree that it doesn't make any sense to give an user the possibility to enter a barcode, that isn't stored in any tag or in the logs, and that, at the only place where it's supposed to appear (in the CUE sheet), is silently overwritten with some kind of secret value, that is not even shown to the user. Usually users know what they are doing when assigning values to tags ...

At least, if you absolutely insist on using the disc-stored barcode, this should be made unmistakably clear to the user by

1) always displaying the disc-stored barcode in the "Barcode" field (instead of displaying some barcode retrieved from freedb or some other metadata source, as these are obviously completely irrelevant to CUERipper), and

2) greying out the "Barcode" field, to make it clear to the user, that the content of this field can't be edited.

However, I think the easiest way would be to simply allow the user to edit this field and store its value in a tag and in the cue sheet.
You can always add some kind of "always use disc-stored barcode" option under extraction and use this as default setting for CUERipper.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-08-31 14:49:12
Slight chance the Barcode entry could revert back to what was retrieved from the db due to this bug ...


I'm aware of this bug, but the phenomenon I described is a general one, not related to this bug.

Of course if the Barcode field was blank before the manual entry, the 'other number' isn't coming from the retrieved metadata.


Of course not. As we both know now from Gregory's answer, it's coming from the disc itself.
This also explains that, even if some metadata was retrieved and was left unchanged, the value actually used by CUERipper usually doesn't
match this data, which is very confusing.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2013-09-03 04:18:25
Well, everyone has different expectations of what should be in the cue sheet and what should be in the tags. I feel that cue sheets shouldn't contain any data that wasn't read from the disc itself. Or there should be a separate cue sheet which has all the external data in it. Also there should be an indication in comments of what was and wasn't scanned for; e.g. I want to know if missing data just wasn't found, or if it wasn't even checked for. Dream on, I guess.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: shaboo on 2013-09-13 13:21:10
Well, everyone has different expectations of what should be in the cue sheet and what should be in the tags. I feel that cue sheets shouldn't contain any data that wasn't read from the disc itself.


Using REM, you can include arbitrary information in the cue sheet and there's absolutely no reason not to do this, as this doesn't compromise the integrity of any data that was read from the disc itself. Having an album comment or an album replay gain value, it absolutely makes sense to write these values in the cue sheet. If you don't need them, then simply don't use them, but they'll never hurt. You don't need a separate cue sheet for this. In addition, that was not my point. My point was, that, specifically regarding the barcode tag, it doesn't make sense to give an user the possibility to enter a barcode, that isn't stored in any tag or in the logs, and that, at the only place where it's supposed to appear (in the CUE sheet), is silently overwritten with some kind of secret value, that is not even shown to the user.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dannytran1191 on 2013-09-29 17:33:17
Can you please add a way to manually select CD tracks for CueRipper? Make sure to add a checkbox on top of all the others so we can select/deselect multiple tracks at once. Appreciate it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: echofu on 2013-09-29 18:15:05
Windows DPI Scaling problem with CUETools 2.1.4 (I haven't used any other versions)

when using Larger scale DPI (120) in Windows Vista, the Offset box in the 'extra' section of CUETools is not visible.

resizing or maximizing the window does not help.  the only way I can see and use the Offset box is to change the DPI back to 96 (Default), which makes everything else too small.

(http://members.westnet.com.au/eksere/cuetools120dpi.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-09-29 20:06:02
echofu,
Known issue. See [a href='index.php?act=findpost&pid=840158']this post[/a] or [a href='index.php?act=findpost&pid=800027']this post[/a] in this thread, or the bug tracker (http://sourceforge.net/p/cuetoolsnet/bugs/10/).

[EDIT] I'm using a custom size of 106 DPI (110%) without issue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2013-10-22 13:00:07
WavPack v4.70 is out. Really hope to see it in v2.1.5
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2013-11-07 16:27:20
I'm trying to run cuetools on linux using Mono. It starts but complains that flac is not supported. And when I try to go to settings it crashes. Tested on 2.1.4 and 2.1.5. I've found deeper in this thread that people were able to run it. Anybody else having these issues?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: unfinished.hide on 2013-11-07 17:20:57
The last time I checked some time ago already, Cuetools wasn't working correctly with mono nor with wine + mono for windows which afaik it is the default wine configuration to run .Net applications. The workaround I found was to install the required dependencies for windows through the command winetricks (.Net 2.0, .Net 2.0 SP2 and the Visual C++ 2008 libraries) under a 32-bit wineprefix or the installers wouldn't work:

winetricks dotnet20sp2
winetricks vcrun2008

(the first command installs both, the main package and the service pack)

After doing this, at least here under Arch, everything seems to be working fine with no big issues so far.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: drfr on 2013-11-12 17:41:47
After doing this, at least here under Arch, everything seems to be working fine with no big issues so far.


I've had some issues with wine (couldn't figure out how to setup 32-bit winprefix) so I did the easier way, using Playonlinux. After installing  dotnet20sp2 and vcrun2008 everything works fine. Thanks.
Btw I'm on Manjaro (arch based distro).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zyklee on 2013-11-20 07:52:05
I'm trying to split a .cue file into separate .flac files but for some reason I keep getting a Exeption: Access to 'D:\User\Desktop' is denied. I have full administrative rights. I tried another path but the same thing happens. Everything was working fine last night. The only big change that I did since then was change my system locale but I've changed it back. Thanks for the help!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nospamorban on 2013-12-09 08:59:14
CUETools v2.1.4

Artist.Album.Year.cue
Artist.Album.Year.flac
Artist.Album.Year.log (with checksum)



When splitting a Disc Rip (ie. All Tracks in a Single FLAC file) with CUETools into individual FLAC files.

CUETools somehow amends the log file in the destination folder (that also contains the newly split individual flac tracks and cue file)

which makes it fail (no checksum found or something to that effect) EAC's CheckLog.exe.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2013-12-09 14:46:10
EAC's CheckLog only work with the original flac 'image' and cue sheet. Testing the log with the individual tracks will make the log check fail.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nospamorban on 2013-12-10 12:49:03
EAC's CheckLog only work with the original flac 'image' and cue sheet. Testing the log with the individual tracks will make the log check fail.



What?

EAC's CheckLog just checks the log to verify that it has not been altered/edited/modified in any way.

It doesn't check the log against any flac file (disc or individual tracks)...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-12-10 13:50:51
CUETools somehow amends the log file in the destination folder (that also contains the newly split individual flac tracks and cue file)

which makes it fail (no checksum found or something to that effect) EAC's CheckLog.exe.

CUETools 2.1.4 rewrites the extraction logfile ANSI. Later versions of EAC write the extraction logfile Unicode.
CUETools 2.1.5 does this also.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nospamorban on 2013-12-10 17:40:24
CUETools 2.1.4 rewrites the extraction logfile ANSI. Later versions of EAC write the extraction logfile Unicode.
CUETools 2.1.5 does this also.



Oh okay. Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2013-12-10 19:04:59
CUETools 2.1.5 does this also.

Oops
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2013-12-11 21:30:57
i'm sure i've had the tak decoder working before but i can't get it working at all now.  all i'm looking to do is verify files. if i try and modify the path to takc.exe in the options, it doesn't make any difference. also, on a restart, this change is lost and it resets to default. i've also tried putting takc.exe in the cuetools folder and that didn't work either. this is the error:

Quote
Object reference not set to an instance of an object..


using 2.1.5.

edit: 2.1.4 works fine. i can set the path to takc.exe in my encoders folder, job done. i guess i must have used that previously.. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d125q on 2013-12-15 11:21:39
i'm sure i've had the tak decoder working before but i can't get it working at all now.  all i'm looking to do is verify files. if i try and modify the path to takc.exe in the options, it doesn't make any difference. also, on a restart, this change is lost and it resets to default. i've also tried putting takc.exe in the cuetools folder and that didn't work either. this is the error:

Quote
Object reference not set to an instance of an object..


using 2.1.5.

edit: 2.1.4 works fine. i can set the path to takc.exe in my encoders folder, job done. i guess i must have used that previously.. 


Hi marc2003,

It is funny how I just wanted to post the same issue. Have you been able to solve this and use Takc.exe with CUETools 2.1.5?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2013-12-15 12:21:48
nope, i'm just running 2.1.4 now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d125q on 2013-12-15 14:12:03
Bummer. 2.1.5 has so many improvements over 2.1.4.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: raster43 on 2013-12-17 20:37:28
@d125q....could you elaborate please.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2013-12-18 16:41:59
Since when is 2.1.5 the current version? On the website it's still marked as a dev-version.
Does this mean support for cards with Compute Capability <1.2 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=2350&p=839605&#entry839605) will be dropped?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: oleg1000corsar on 2013-12-20 06:20:27
HI,
help needed, aplaing offset with CT CRC first track missmatch. How to correct it (may be digital silence somewhere is missing)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-12-20 13:37:27
Quote
CRC first track missmatch.

This is a bit vague. Which CRC?
Example: If the FLAC decoder throws a "Frame CRC Mismatch" error when track1.flac is input into CUETools then that FLAC file is likely corrupt.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: oleg1000corsar on 2013-12-20 14:40:48
O.K.,
Some CD Rips (ripped according EAC for 100% copy) ONLY SOME rips do not shift (when applying offset correction) properly:
1.I take (Flac/APE) CDimage+Cue+Log
2.Using CUEtools - to verify CRC32 whole CDimage and tracks if they are accurately ripped (they are !)
3.My CD drive offset is +6
4.burning software is NERO
5.With CUEtools I apply offset +6 to this wave CDimage
6.Using CUEtools - to verify CRC32 whole CDimage and tracks if they are shifted correctly BUT...,
first and last tracks CRC32 mismatch to CDimage before applying offset +6
THAT is a PROBLEM

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-12-20 19:34:22
When you apply offset, samples are lost at one end of the wav image and null samples padded to the other. The CRC32 (null samples included in calculation) of the wav image (and each track) will change.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d125q on 2013-12-20 19:40:26
O.K.,
Some CD Rips (ripped according EAC for 100% copy) ONLY SOME rips do not shift (when applying offset correction) properly:
1.I take (Flac/APE) CDimage+Cue+Log
2.Using CUEtools - to verify CRC32 whole CDimage and tracks if they are accurately ripped (they are !)
3.My CD drive offset is +6
4.burning software is NERO
5.With CUEtools I apply offset +6 to this wave CDimage
6.Using CUEtools - to verify CRC32 whole CDimage and tracks if they are shifted correctly BUT...,
first and last tracks CRC32 mismatch to CDimage before applying offset +6
THAT is a PROBLEM

Try looking at the W/O NULL entry.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tahaa7 on 2013-12-23 14:21:07
I have a rip of one of my CDs made originally with Read Offset: 0. The correct read offset for the drive used is 48. Can I fix that using CUETools by selecting the "Encode" action and entering 48 as Offset in "Extra" section? Or is that not the method to do that? Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d125q on 2013-12-23 20:46:28
I have a rip of one of my CDs made originally with Read Offset: 0. The correct read offset for the drive used is 48. Can I fix that using CUETools by selecting the "Encode" action and entering 48 as Offset in "Extra" section? Or is that not the method to do that? Thanks.

That is exactly the method of doing it. Just be sure that the offset should be 48 before doing it (look at AccurateRip logs, offset databases, and so on).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: gib on 2013-12-24 07:20:35
Do be aware that 48 samples is only about 1/1000th of a second and you don't gain anything by re-encoding the original rip with that offset.  It's not more accurate or better.  Since CueTools can verify the rip as is, you might consider just leaving it alone.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: goa pride on 2013-12-24 13:30:25
the problem is i can't extract some tracks and not all tracks from cd!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ligerpants on 2013-12-27 18:53:56
It is funny how I just wanted to post the same issue. Have you been able to solve this and use Takc.exe with CUETools 2.1.5?


I'm using takc.exe v2.3.0 with both the latest beta and CT v2.1.4, no problem. Not sure what I'm doing differently.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2013-12-27 21:36:33
I also get the exception in 2.1.5 using takc.exe v2.3.0
Quote
Object reference not set to an instance of an object.

on decode. Encoding is fine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ligerpants on 2013-12-27 23:06:47
I have the path set to just 'takc.exe' with the executable in the 2.1.5 base folder, and the parameters are: '-d %I -' both without the single quotes. I'm using Win7 x64. Verifying and transcoding from .tak both work fine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ZREXMike on 2014-01-03 14:25:19
Gap detection fails, & CDs will not rip. This happens using CUERipper 2.1.4. Any ideas? Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-01-03 16:12:14
OS and hardware info (such as optical drive make & model and connection type) might be helpful to the developer.
Does it rip OK with Detect Indexes (http://www.cuetools.net/wiki/CUERipper_Options) turned off?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-01-03 18:01:56
You didn't say if you had Test&Copy ticked. There was a problem with this on some drives in 2.1.4 (fixed in 2.1.5).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: A_Man_Eating_Duck on 2014-01-03 22:23:33
I was wondering if there was any thought of adding a more stream lined ripping approach similar to how DBPoweramp works?

1. Rip as burst, compare tracks to AccurateRip results. If they all match, ripping done. If they don't all match move to step 2
2. Re rip non matching AccurateRip tracks in secure mode.
3. Report any ripping errors.

So there is no user interaction between steps 1 - 3.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ZREXMike on 2014-01-04 02:45:14
OS and hardware info (such as optical drive make & model and connection type) might be helpful to the developer.
Does it rip OK with Detect Indexes (http://www.cuetools.net/wiki/CUERipper_Options) turned off?


Was HP DVDRAM GT31L, a new drive I got when the one that worked fine, GT20L, went out. Works fine with dBpoweramp 14.4 Trying 2.1.5 now, will see about this index thing. Thanks.

-------------------------------------------------------------------------

Okay, 2.1.5 working fine!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: justonce01 on 2014-01-06 10:00:46
Can someone explain what the %O and "-" parameters exactly do?

Code: [Select]
Arguments for external encoder executable. The required placeholder arguments used by CUETools for external encoders are: 

        " - " (without the quotes) = input filename.
         %O = output filename.
         %M = Modes selection.


The information from the Wiki is a bit vague, at least for me. I figured out what %M does, but fail to grasp what "-" and %O do and why I get an error code -1 (with LAME) when I leave them out.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-01-06 13:13:38
From the LAME documentation:
[blockquote]lame [options] inputfile [outputfile]
inputfile and/or outputfile can be "-", which means stdin/stdout.[/blockquote]CUETools uses - for stdin (standard input) and %O for stdout (standard output).
stdin/stdout are used to stream the audio data through the LAME encoder instead of using inputfile outputfile as shown in the LAME documentation.

Each encoder may have different usage parameters
From the Nero AAC Encoder documentation:
[blockquote]Usage:
neroAacEnc [options] -if <input-file> -of <output-file>

Where:
<input-file>  : Path to source file to encode.
                The file must be in Microsoft WAV format and contain PCM data.
                Specify - to encode from stdin.
<output-file> : Path to output file to encode to, in MP4 format.[/blockquote]So to use in CUETools you would replace <input-file> with - and <output-file> with %O.

Edit: added another example.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: justonce01 on 2014-01-10 17:51:01
Thank you for the explanation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Owen Smith on 2014-01-23 12:46:04
Is CUETools 2.1.5 still considered experimental? It's been out for more than six months according to the changes log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: n0v!ze on 2014-01-25 09:24:31
OK, I'm not a CUETools expert and I can't tell whether this is by design or by error. When looking up the 2008 Century Media reissue of Heathen - "Breaking the Silence" with MusicBrainz, this is not displayed in the list of albums. Only the older 2000 Century Media reissue is offered. As it seems only the first album with matching track count is offered, not all, which prevents me from selecting the correct release.

(http://imageshack.com/a/img600/8666/tk1n.jpg)

(http://imageshack.com/a/img17/7835/rvai.jpg)

I'm using CUETools v2.14
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: n0v!ze on 2014-01-25 09:26:09
<double post>
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-01-25 13:10:46
No Musicbrainz Disc ID (http://musicbrainz.org/release/c7c216e8-e523-4999-894d-43635b3571e9/discids) (CD TOC) listed for the 2008 Century Media release. The 'Default' Metadata search (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB) in CUETools will not display these if exact Musicbrainz Disc ID matches are found. Your image TOC was probably an exact match for a Musicbrainz Disc ID (http://musicbrainz.org/release/6014e5e5-89e1-49e3-b670-51250d13cefa/discids) under the 2000 Century Media release. You could try the 'Extensive' setting.

edit: fixed link
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Padman on 2014-01-29 15:24:04
Hello,

is there a translation tool or similar?

The German translation is not completely correct and some is still missing.
Under plugins there is only one translation for Russian.

How can a user change the language in the programs?

Thanks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-01-29 16:30:10
The developer provides the Russian. German translations are provided by a 3rd-party and they may not be 100% up-to-date. No other translations are provided at this time.
Quote
How can a user change the language in the program?
In CUETools, see the CUETools tab (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools) in Advanced Options.
In CUERipper you can change in the \CUERipper\settings.txt file located under %appdata% (or in program folder if you are running as a portable app).
look for Language=
the following are supported:
Language=en-EN
Language=ru-RU
Language=de-DE
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Padman on 2014-01-29 21:58:15
[...] German translations are provided by a 3rd-party and they may not be 100% up-to-date. No other translations are provided at this time.

I thought, that I can correct and insert text in the language file. I tried it with Lingobit Localizer, but the created file is invalid for CUERipper and so.

Quote
How can a user change the language in the program?
Quote
In CUERipper you can change in the \CUERipper\settings.txt file located under %appdata% (or in program folder if you are running as a portable app). [...]

OK, I've found it.

In CUERipper (in German):
Code: [Select]
Codepage = Zeichensatz
Eject = Auswerfen
lossless = verlustfrei
lossy = verlustbehaftet
Close = Schließen
Tracks = Titel
Burst = (no idea yet)
Secure = Sicher
Paranoid = Paranoid
Image = 'Abbild' or 'Eine Datei', 'Als eine Datei'
Tracks = 'Titel' or similar
...

Offset lesen = 'Leseversatz', 'Versatz beim Lesen' or 'Versatz lesen'
Testen & Kopieren = Prüfen und Kopieren
...
Offset was set to +6, oh, I saw the offset value on accuraterip.com/driveoffsets.htm 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-02-05 20:48:02
Just wanted to say a huge thanks to Gregory for implementing the repair functionality - I just found out one of my tracks got corrupted somewhere and even made it into my (simple) backups. I don't even have that CD anymore, so I was pretty much screwed - but CUETools managed to repair it and it now even verifies against CTDB with highest confidence possible!

A suggestion though, when in "repair" mode, it should instruct the decoder to decode through errors if possible, I had to manually decompress the flac in question to wav using commandline, then edit the .cue and attempt a repair again.

What is the maximum error count CUETools can repair that way? It managed to fix 8190 errors in this case.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lostintranslation on 2014-02-06 14:40:25
Hello
I recently downloaded cuetools, mainly for cueripper
found great not to have to set many parameters

but I when I read the log file, I found:
Overread into Lead-In and Lead-Out        : No
Fill up missing offset samples with silence  : Yes

afaik the old plextor I'm using can overread into lead-in and lead-out (I think I bought it especially because it could do everything)
[kind of edit : humm, I just checked the DAE drive database to refresh my mind about what meant "do everything" and noticed that "C2 pointers" is YES in this table, but logfile by cueripper says "Make use of C2 pointers : No" Dont know what to think about that]

if I'm not wrong, I read in a 1 or 2 year's old post that this overreading thing was not implemented yet, but on the way
any news from it?

well, to be honest, I'm not sure how important this is (this point is not listed in the "Comparison of CD rippers" page)
I thought it was closely related with the htoa thing, but apparently not

the offset of the drive I use is +30 (I don't know if this information is of any interest regarding my questions, but I assumed that the smaller the offset is, the better it is if no overreading, am I right?)

thanx to anyone enlightening the ignorant I am
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-02-06 15:40:41
What is the maximum error count CUETools can repair that way? It managed to fix 8190 errors in this case.

In theory the matrix of the 188160 byte recovery record can repair up to 10 sectors (5880 samples) * 4 errors = 40 sectors (23520 samples) max for one continuous damaged section. Starting with CTDB 2.0, popular CDs can have recovery records of twice that size. See this [a href='index.php?act=findpost&pid=697686']post[/a], the wiki: How many errors can a rip contain and still be repairable? (http://www.cuetools.net/wiki/CUETools_Database#How_many_errors_can_a_rip_contain_and_still_be_repairable.3F) and Changelog: 16.04.2012: CUETools 2.1.4 (http://www.cuetools.net/wiki/CUETools_Changelog#16.04.2012:_CUETools_2.1.4:).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2014-02-07 01:23:55
the offset of the drive I use is +30 (I don't know if this information is of any interest regarding my questions, but I assumed that the smaller the offset is, the better it is if no overreading, am I right?)


Overreading is not related to HTOA, really. All drives are supposed to be able to read the entire program area, which is where the audio data is supposed to live, in between the lead-in and lead-out zones (which are normally short, inaccessible silent tracks). It doesn't matter if the beginning of the program area is track 01 index 01, or track 01 index 00 (HTOA).

If your drive is reading from 30 samples prior to where it's told to (hence correction value +30), then theoretically it is overreading into the lead-in a little, but that doesn't mean it can be told to read a full sector from outside of the program area, or that even if told to, it would actually do it. However, we now are pretty confident that our standard for offset correction as used by AccurateRip is actually off by 30, so your drive is actually reading from precisely where it's told to.

Since your true offset is 0, to get a "perfect rip" you don't need to overread; your drive can everything from the program area if you use 0 as your correction value. By using +30, you're actually discarding 30 good samples from the beginning of your rip. We're talking about a fraction of a millisecond of what is almost certainly silence. If overreading were implemented and your drive were capable of it, the first 30 samples from the first sector of lead-out would be added to the end, but for now, 30 silent samples are used instead. The downside to using offset 0 is AccurateRip comparisons will be off by 30, of course.

Personally I think overreading is very low priority. Even a large offset is only affecting a fraction of a second of extra audio on one end or the other of what is arguably a poorly mastered disc. It's not needed for AccurateRip (which ignores 5 sectors on either end), and most CDs have a buffer of silence at both ends anyway, so it's a lot of work to try to get what is usually going to be silent samples or quiet hiss.

As for C2, I don't know why CUERipper's EAC-style log says CUERipper is not using C2. It is using them, if the drive provides them. It is not exactly the same way that EAC uses them, but I don't think the difference warrants a "no" in the log. Maybe I'm wrong.

My understanding of C2: Using validation & error correction data on the CD, the drive normally does its own minor corrections of "burst" errors on small batches of samples, then reports the whole batch as 100% correct, same as if the batch didn't need correction. If the batch has too many errors, or the validation codes are bad, it isn't able to tell how many errors and where they all are, so it reports the whole batch as "uncorrectable", even though some or all of the samples may actually be correct; they're just not fixable by the C2 system if they happen to be wrong. Drives vary widely in what C2 data they report and how accurate it is, so there's disagreement over how rippers should use the info.

EAC secure mode tries to get consistent data by re-reading everything. If the C2 option is enabled, EAC skips its usual round of re-reads if the drive doesn't say there's any uncorrectable data. CUERipper does the same but stops the re-reads if the drive says the data wasn't uncorrectable. So CUERipper is a little more trusting of the drive's C2 reports than EAC. Is that good or bad, who knows...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-02-08 23:20:02
Would it be possible to add some ways to work around non-utf-8 compatible encoders (namely, takc), by maybe including an option to use temporary names during encode/verify? Currently I'm getting a not very useful "the pipe has ended" error on any non-ansi names...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Static on 2014-02-10 13:17:14
I have a question about tagging, not sure if this is the right place to ask. I am trying to batch convert from multiple flac files (no cue) to multiple mp3 files, but all my tags (from flac files) are erased during the conversion process. Any option to preserve my tags? I have all the options from settings (write basic tags, copy basic tags, etc.) checked if that helps.

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-02-10 13:56:57
You didn't say which version of CUETools. Try setting Metadata search (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB) to 'none' in 2.1.4 or 2.1.5.

[edit]
alternative
In 2.1.4 you could un-tick 'use MusicBrainz' and 'use freeDB' under Mode.
In 2.1.5 you could un-tick 'edit tags' under Mode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Static on 2014-02-10 14:03:22
I am using version 2.1.4. I have tried with both 'Default' and 'Extended' for Metadata Search and no tags are written.

[edit:]

I have tried with 'None' option and also no tags. I can't seem to find the Mode option.

[edit:]

I have found the Mode option, un-checked both option. Still no tags.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-02-10 14:49:05
Sorry, I incorrectly assumed 'replaced' rather than 'empty'.

You say everything on the 'tagging' tab is checked.
You are using the built-in libmp3lame. (?)
No error messages.

Tags are written last after all the audio files are written so CUETools needs to be able to edit the audio files. Did you try an alternate output location? Something may be preventing CUETools from editing the files.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-02-10 14:55:18
Also what software are you using with resulting files? It might be the case that the tags are there, just not in the format the software expects. By default CUETools used Id3v2 tags with mp3 format.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Static on 2014-02-10 15:48:26
Actually, I have found out what was happening. I only tried with one file at a time, but the tags apparently are written at the end.

Once I have tried with an entire album, it worked, tags are visible and recognized by foobar2000.

Thanks for the help!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: userx2048 on 2014-02-11 13:43:54
I have come across a cd rip that I cannot transcode trough libALAC at compression levels from 3 to 10. I have isolated the specific track and tried to input it as FLAC and WAV with no success. The verification fails and if I disable it and hex compare the WAV extracted from the output file with the original there are large mismatching regions in the middle of the WAV file. Setting lower compression levels (from 0 to 2) results in perfect hash matching audio (when transcoded back to WAV). As it has been one file out of 500~ it seems to be some kind of encoder bug and I would like to submit the file somewhere for testing purposes. Encoding the same file trough iTunes also outputs hash matching audio.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2014-02-17 22:37:29
I dug my way back to last July to find that the below quoted bug has been reported.  Just to confirm, I have got a similar error message. In 2.1.4 and then after upgrading, in 2.1.5.

Also I got objections over HDCD (which there isn't?) and Cuetools terminating after encoding pregap - that is a known one?


Just tested the newest 2.1.5, got an exception closing CUETools:
Code: [Select]
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.


(Citation cut after first codebox line. Edit: and codebox altered to code)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rireinc on 2014-02-25 04:16:59
Hi.

Thanks for this awesome software

I've been using it quite some time now but I have some questions...
I'm coverting some flac images to mp3 V0 tracks for my portable devices, but I dont know how to join two tracks into one when converting...

Example:

My pink floyd's pressing of Dark side of the moon has the first two tracks splitted (Speak to me/Breathe) which are suppossed to be together, but when converting CUE TOOLS also splits them...

Any way to split the album in tracks but join two or more while converting? 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-02-25 04:23:28
Any way to split the album in tracks but join two or more while converting? 

CUETools doesn't support that, and it probably never will. It's not what CUETools is for. You can easily merge two tracks with foobar2000.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rireinc on 2014-02-25 04:27:26
Any way to split the album in tracks but join two or more while converting? 

CUETools doesn't support that, and it probably never will. It's not what CUETools is for. You can easily merge two tracks with foobar2000.


Thanks! Will do.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: eahm on 2014-02-25 04:51:49
My pink floyd's pressing of Dark side of the moon has the first two tracks splitted (Speak to me/Breathe) which are suppossed to be together, but when converting CUE TOOLS also splits them...

They are not, well, it actually depends on the press used. The 1st press of "The Dark Side of the Moon" for example has them together and "Breathe" is called, in the second part of the song, "Breather in the Air".
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: iceolate on 2014-03-09 15:10:13
Been trying to get this software running since yesterday and it's really frustrating. I'm on a fresh install of Windows 7, 64 bit. .Net was already installed and I installed the Visual C++ prereq. Every time I run cueripper or cuetools, it merely says that it "stopped working'. Any have some thoughts to what I can check before I give up and install a different program?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-03-09 22:43:35
The wiki says "Just unpack the archive to any folder" but you will likely to run into 'permissions' problems if you try to run from within the 'Programs Files' directories on Win7.
Also some security software may restrict the program until you tell that software to allow the program to run normally.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: klfree on 2014-03-14 12:50:59
Good day.

I have a problem with creating cue from flac files using cuetools. Cue entry looks like this:

REM COMMENT "cuetools generated dummy CUE sheet"
  FILE "Amerika.flac" WAVE
  TRACK 01 AUDIO
  INDEX 01 0:00:00
  FILE "Wilder Wine (Exclusive Track). Flac" WAVE
  TRACK 02 AUDIO
  INDEX 01 0:00:00

Unfortunately, this my XBMC only shows track number and not the name of the song. I note that the tags correctly I have done. If I create cue in Foobar in XBMC is already displayed properly track is called - cue already contains the name of the song. Please respect somehow compel cuetools to create cue correctly according to my expectations?

Thank you.
PS: Excuse my English - Google Translate
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-03-14 13:18:15
Is "Fill up missing CUE data from tags (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging)" enabled (checked)? This option allows the copying of audio file tags to missing CUE data.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dudism on 2014-03-14 13:25:49
I'm a newbie here and I just wanted to say that cuetools is an excellent program but I really wish it could verify against accurateRip as well as perfectTunes does.


"Calculate crc32 and accurateRip crc"
CRC32      AccurateRip CRC      Filename

0CCB0623   394B74FF      C:\check audio\02 Kaleidoscope.flac
ACC98232   8D928C86      C:\check audio\01 Seagull.flac
D388A614   C7E7C109      C:\check audio\03 In A Different Place.flac
9B086738   7AD05C99      C:\check audio\04 Polar Bear.flac
A29D895F   34157A27      C:\check audio\05 Dreams Burn Down.flac
02F9206B   E3CDFB38      C:\check audio\06 Decay.flac
A9ADC154   A360DB34      C:\check audio\07 Paralysed.flac
FAECC854   7A70C28F      C:\check audio\08 Vapour Trail.flac
A1CD0D39   6E7FE4EA      C:\check audio\09 Taste.flac
185763C9   174DCBA0      C:\check audio\10 Here And Now.flac
BBBFEBDE   DAD10A25      C:\check audio\11 Nowhere.flac


perfectTunes accurateRip verification
Ride - Nowhere  [AccurateRip DiscIDs: 011-0015F267-00BCCCA1-960C3D0B]
  Track 1: AccurateRip Verified Confidence 18, Pressing Offset +0 [ARv2 CRC 5C9B2532]  C:\check audio\01 Seagull.flac
  Track 2: AccurateRip Verified Confidence 20, Pressing Offset +0 [ARv2 CRC 728B227E]  C:\check audio\02 Kaleidoscope.flac
  Track 3: AccurateRip Verified Confidence 19, Pressing Offset +0 [ARv2 CRC 2C33EAD9]  C:\check audio\03 In A Different Place.flac
  Track 4: AccurateRip Verified Confidence 19, Pressing Offset +0 [ARv2 CRC A419D36B]  C:\check audio\04 Polar Bear.flac
  Track 5: AccurateRip Verified Confidence 19, Pressing Offset +0 [ARv2 CRC 5380AA84]  C:\check audio\05 Dreams Burn Down.flac
  Track 6: AccurateRip Verified Confidence 18, Pressing Offset +0 [ARv2 CRC 134132A3]  C:\check audio\06 Decay.flac
  Track 7: AccurateRip Verified Confidence 18, Pressing Offset +0 [ARv2 CRC 5C4DC17C]  C:\check audio\07 Paralysed.flac
  Track 8: AccurateRip Verified Confidence 19, Pressing Offset +0 [ARv2 CRC 4D683A84]  C:\check audio\08 Vapour Trail.flac
  Track 9: AccurateRip Verified Confidence 19, Pressing Offset +0 [ARv2 CRC C4267185]  C:\check audio\09 Taste.flac
  Track 10: AccurateRip Verified Confidence 19, Pressing Offset +0 [ARv2 CRC 0882ABC1]  C:\check audio\10 Here And Now.flac
  Track 11: AccurateRip Verified Confidence 19, Pressing Offset +0 [ARv2 CRC FCA72F5F]  C:\check audio\11 Nowhere.flac


cuetools auccrateRip verification

[CUETools log; Date: 14/03/2014 13:20:12; Version: 2.1.5]
[AccurateRip ID: 0015f0db-00bcc294-8f0c3d0b] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]  - yet the values in the following section are always correct
--  100.0 [D56146E0] [A0D3C40F]         
01  99.2 [ACC98232] [080BBE1B]         
02  100.0 [0CCB0623] [4C85CA61]         
03  99.5 [D388A614] [31A68A71]         
04  100.0 [9B086738] [DD631802]         
05  100.0 [A29D895F] [EBD21822]         
06  100.0 [02F9206B] [FFEA508E]         
07  100.0 [A9ADC154] [3033B357]         
08  100.0 [FAECC854] [5BCE0AEB]         
09  100.0 [A1CD0D39] [4181CD9D]         
10  100.0 [185763C9] [27DBA1F6]         
11  95.3 [BBBFEBDE] [C0FE0066]         


This happens so often, but I'm confident these bugs will get fixed one day. Until then I will keep verifying with perfectTunes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: klfree on 2014-03-14 13:29:08
Is "Fill up missing CUE data from tags (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging)" enabled (checked)? This option allows the copying of audio file tags to missing CUE data.



I understood when I get home from work at the machine look into this option.
Thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-03-14 13:45:16
dudism,
perfectTunes [AccurateRip DiscIDs: 011-0015F267-00BCCCA1-960C3D0B]
cuetools [AccurateRip ID: 0015f0db-00bcc294-8f0c3d0b]
The difference in the lookup ID can come from missing disc pregap or data track info.
This looks like disc pregap (but I'm not going to try to figure out what album this is to confirm). CUETools can find this info in the CUE sheet, an EAC log file (if in same folder) or CDTOC tag (in 2.1.5).

EDIT: This is Ride - Nowhere. It is likely this (http://musicbrainz.org/cdtoc/3UGbRnM_ENU4B_rsh7SEfV_8jDY-) with a pregap of 00:00:32
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dudism on 2014-03-14 14:14:16
dudism,
perfectTunes [AccurateRip DiscIDs: 011-0015F267-00BCCCA1-960C3D0B]
cuetools [AccurateRip ID: 0015f0db-00bcc294-8f0c3d0b]
The difference in the lookup ID can come from missing disc pregap or data track info.
This looks like disc pregap (but I'm not going to try to figure out what album this is to confirm). CUETools can find this info in the CUE sheet, an EAC log file (if in same folder) or CDTOC tag (in 2.1.5).


I really appreciate that information Korth. I personally don't use cue files because I just stream FLAC to my hifi. I have however found cuetools reliable for verifying without cue files, on approximately 70% of albums. For the albums that don't verify then I use perfectTunes to verify.

One thing that is still confusing me is that if "CDs in the AccurateRip database are identified by the track lengths, with "the track 01 pregap" and data tracks included, then why can perfectTunes always perform the correct lookup without that information? E.g. perfectTunes doesn't require cue files, it just seems to pass the CRC values which returns the correct album and result.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-03-14 14:22:32
Sorry I'm not that familiar with perfectTunes to know if (in addition to track lengths) it makes use of the AccurateRip database, some other database or some other tag data to get the correct lookup ID.
The CUETools database contains separate pregap data but CUETools doesn't currently parse that data when doing AccurateRip lookups.

Can I ask what ripping program was used on this example?


Note: I edited my previous post.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: klfree on 2014-03-14 15:00:27
Is "Fill up missing CUE data from tags (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging)" enabled (checked)? This option allows the copying of audio file tags to missing CUE data.



I understood when I get home from work at the machine look into this option.
Thank you.

So I checked. It is ticked and overwrite the original cue, but even that will not be overwritten. I enclose a cue from Foobar created from the same flac.

REM GENRE Industrial
REM DATE 2004
PERFORMER "Rammstein"
TITLE "America"
FILE "Amerika.flac" WAVE
  TRACK 01 AUDIO
    TITLE "America"
    PERFORMER "Rammstein"
    ISRC 9868673
    INDEX 01 0:00:00
FILE "Wilder Wine (Exclusive Track). Flac" WAVE
  TRACK 02 AUDIO
    TITLE "Wilder Wein"
    PERFORMER "Rammstein"
    ISRC 9868673
    INDEX 01 0:00:00
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dudism on 2014-03-14 15:28:40
Sorry I'm not that familiar with perfectTunes to know if (in addition to track lengths) it makes use of the AccurateRip database, some other database or some other tag data to get the correct lookup ID.
The CUETools database contains separate pregap data but CUETools doesn't currently parse that data when doing AccurateRip lookups.

Can I ask what ripping program was used on this example?


Note: I edited my previous post.

That CD was ripped to individual FLAC files using EAC. I never used to bother keeping logs (because the logs never used to make sense to me lol).
perfectTunes is new software by Illustrate (the inventors of AccurateRip).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-03-14 17:37:07
I note that the tags correctly I have done.
So I checked. It is ticked and overwrite the original cue, but even that will not be overwritten.
Sorry, not sure then. I haven't been able to duplicate this other than what I suggested. How were these tagged (what program)? Perhaps the way the tags are written to the audio file may be the problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: klfree on 2014-03-14 17:41:36
They are tagged in the Tagscanner
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acrox999 on 2014-03-19 07:39:35
It seems that CUERipper still have no support for non-Latin or non-English alphabets for the filenames, in the logs, the M3U playlist and the cuesheet. Tags are fine. Those characters will only get replaced by underscores or question marks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2014-03-20 16:30:20
There seem to have been no changes for a while now in the repository. Can we have a recent compile with the last changes applied ~6 months ago?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-03-20 19:18:56
It seems that CUERipper still have no support for non-Latin or non-English alphabets for the filenames, in the logs, the M3U playlist and the cuesheet. Tags are fine. Those characters will only get replaced by underscores or question marks.
It does work on my system, ripping an e.g. Japanese CD works. CUERipper doesn't seem to have as advanced of an options dialogue, but something is telling me it shares settings with CUETools, and CUETools has forcing ansi names as an option:
(https://dl.dropboxusercontent.com/u/19330332/cuetools_ansinames.JPG)

I haven't tried it, but you could try disabling those options in CUETools and see if CUERipper preserves non-latin characters.
If you are using custom command line for the encoder, it could be that the commandline encoder is what is wrecking your filenames, in some cases (TAK), CUETools/Ripper isn't even able to convert/rip files properly.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acrox999 on 2014-03-21 01:52:16
It seems that CUERipper still have no support for non-Latin or non-English alphabets for the filenames, in the logs, the M3U playlist and the cuesheet. Tags are fine. Those characters will only get replaced by underscores or question marks.
It does work on my system, ripping an e.g. Japanese CD works. CUERipper doesn't seem to have as advanced of an options dialogue, but something is telling me it shares settings with CUETools, and CUETools has forcing ansi names as an option:

<image>

I haven't tried it, but you could try disabling those options in CUETools and see if CUERipper preserves non-latin characters. If you are using custom command line for the encoder, it could be that the commandline encoder is what is wrecking your filenames, in some cases (TAK), CUETools/Ripper isn't even able to convert/rip files properly.


Thanks, I've disabled it for now. But my DVD drive died, yet again, after ripping few CDs consecutively. I knew I shouldn't have ripped that album, lots of scratches, and the error check must have strained it too much. I'll try this when I get myself a new drive.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: plugs13amp on 2014-04-11 10:44:56
I've been using CUETools (2.1.4) to rip all my 500+ cds to flac. This was done across several machines to speed the process up and in some cases to get an accurate rip. Is there any way to merge the local databases onto one machine. I know I can merge the metadata, but any imported metadata files are not seen when I try to convert the flacs to mp3, only the cues are shown.

thanks
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-04-23 16:47:52
It seems that CUERipper still have no support for non-Latin or non-English alphabets for the filenames, in the logs, the M3U playlist and the cuesheet. Tags are fine. Those characters will only get replaced by underscores or question marks.
It does work on my system, ripping an e.g. Japanese CD works. CUERipper doesn't seem to have as advanced of an options dialogue, but something is telling me it shares settings with CUETools, and CUETools has forcing ansi names as an option:
{image removed from quote}
I haven't tried it, but you could try disabling those options in CUETools and see if CUERipper preserves non-latin characters.
If you are using custom command line for the encoder, it could be that the commandline encoder is what is wrecking your filenames, in some cases (TAK), CUETools/Ripper isn't even able to convert/rip files properly.

CUERipper has a separate settings file. If running as Windows app it can be found under %appdata% or if running as portable app it can be found in the CUETools program folder. Look for \CUERipper\settings.txt
Change
FilenamesANSISafe=1 (Force ANSI Filenames)
to
FilenamesANSISafe=0 (Don't Force ANSI Filenames)

Test results: File names and Unicode M3U file OK with Cyrillic characters but CUE and LOG were saved as ANSI files so Cyrillic characters are still replaced by question marks.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nospamorban on 2014-05-03 18:36:46
I'm getting a virus alert everytime I start CUETools. This started a couple of hours ago. No problems the day before.
I've been using CUETools for years and have never encountered this...


Cuetools v2.1.4
Avast! Free Antivirus 2014.9.0.2018
Virus Definition Ver: 140503-0

(http://s28.postimg.org/65e96s9t9/avast.png)

I have run a full scan my PC and it hasn't found a virus.

I deleted the old CT folder, redownloaded CT and it still gives me a virus alert when I try to start CT. And each time its a different .dll file that's moved to the virus chest.

Should I clean install Windows? Have I really got a virus or is this a false positive?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zarggg on 2014-05-03 19:34:09
What is the full path of the file in question?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nospamorban on 2014-05-03 20:30:14
What is the full path of the file in question?


C:\Users\Admin\AppData\Local\Temp
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nospamorban on 2014-05-04 10:18:36
I'm getting a virus alert everytime I start CUETools. This started a couple of hours ago. No problems the day before.
I've been using CUETools for years and have never encountered this...


Pretty sure it's a false positive.
I loaded a new VM with just CUETools and Avast and it still produces a virus warning when I start CUETools.
I have reported it to Avast...I wonder how long they'll take to remedy the situation.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-05-04 20:19:43
The "-gen [susp]" ending means it's a generic signature, the heuristics picked it up as a suspicious file. So yeah, a false positive. You can add the file to exclusions in the meantime.

edit: I just noticed the thread title states 2.1.5 is current, but the page still lists it as unstable/experimental. Is this intended?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: cherry99 on 2014-05-08 02:03:39
Hi,

I have a problem with ID3v1 tags in CUERipper and CUETools 2.1.4.
If metadata is in cyrillic (russian) the resulted Id3v1 tags have question marks instead of letters but ID3v2 tags, CUE and LOG are all correct.
If metadata is in english both Id3v1 and Id3v2 tags are correct.
As suggested by korth in post #2479 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=863905) I changed FilenamesANSISafe=1 to FilenamesANSISafe=0 in both settings.txt files but this had no effect on Id3v1.

Any ideas how to fix this?
Or which settings to change in order not to create Id3v1 tags at all?

Thanks

(http://i60.tinypic.com/vsi6i9.png)            (http://i58.tinypic.com/28s9g0k.png)




Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: evildeathinc on 2014-05-08 03:45:57
Cuetools 2.1.4 recently Crashed. Windows 7 x64 Operating System. Please Help.

Here is the Error found.

  Problem Event Name:   CLR20r3
  Problem Signature 01:   cuetools.exe
  Problem Signature 02:   2.1.4.0
  Problem Signature 03:   4ffe16f6
  Problem Signature 04:   mscorlib
  Problem Signature 05:   2.0.0.0
  Problem Signature 06:   5265c965
  Problem Signature 07:   34a9
  Problem Signature 08:   e1
  Problem Signature 09:   System.IO.FileNotFoundException
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:   1033
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-05-08 14:32:12
Hi,

I have a problem with ID3v1 tags in CUERipper and CUETools 2.1.4.
If metadata is in cyrillic (russian) the resulted Id3v1 tags have question marks instead of letters but ID3v2 tags, CUE and LOG are all correct.
From what I know, ID3v1 is ANSI only. This means, your locale has to be set to Russian while writing Russian tags, and they will only appear as such as long as you have your system locale set to Russian.
ID3v2.x on the other hand support unicode (UTF-16 for v2.3 and UTF-8 for v2.4 afaik), which is the reason why the tags are correct even if your locale is not set to Russian.

Why are you writing v1 tags in the first place? If you don't have to keep compatibility with old devices, don't write ID3v1 at all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: cherry99 on 2014-05-08 18:59:35
Hi,

I have a problem with ID3v1 tags in CUERipper and CUETools 2.1.4.
If metadata is in cyrillic (russian) the resulted Id3v1 tags have question marks instead of letters but ID3v2 tags, CUE and LOG are all correct.
From what I know, ID3v1 is ANSI only. This means, your locale has to be set to Russian while writing Russian tags, and they will only appear as such as long as you have your system locale set to Russian.
ID3v2.x on the other hand support unicode (UTF-16 for v2.3 and UTF-8 for v2.4 afaik), which is the reason why the tags are correct even if your locale is not set to Russian.

Why are you writing v1 tags in the first place? If you don't have to keep compatibility with old devices, don't write ID3v1 at all.

I would prefer not to write ID3v1 tags but CUETools always creates them automatically. If anyone knows how to stop ID3v1 creation please let me know.

My locale was always set to Russian, so that is not the reason.

To isolate the problem I did the following test:
I ripped a CD with EZ CD Audio Converter in Russian locale and both ID3v1 and ID3v2 were written correctly.
Then I changed locale to English (United States) and ripped the same CD with EZ CD Audio Converter and again both ID3v1 and ID3v2 were written correctly.
Then I repeated the same process with CUERipper and ID3v1 tags were always written with question marks instead of letters.
The conclusion: It is not the System Locale that is responsible for wrong ID3v1 characters but something in CUETools. But what...?

Any suggestions?

Ripped by EZ CD Audio Converter
(http://i59.tinypic.com/1zlcbdd.png)        (http://i58.tinypic.com/10z2wrd.png)
                                                                       

Ripped by CUERipper
(http://i62.tinypic.com/28h3jmh.png)      (http://i60.tinypic.com/2zjglxj.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: plugs13amp on 2014-05-11 09:40:01
I'm getting a virus alert everytime I start CUETools. This started a couple of hours ago. No problems the day before.
I've been using CUETools for years and have never encountered this...


Cuetools v2.1.4
Avast! Free Antivirus 2014.9.0.2018
Virus Definition Ver: 140503-0

(http://s28.postimg.org/65e96s9t9/avast.png)


Avast still flagging CueTools as infected on 11th May 2014

I've also now reported the problem to Avast, maybe those of us experiencing the problem can report it, to push them along.

The offending .dll appears to be created dynamically with a different filename on each run by both CueTools and CueRipper, so you can't simply exclude the file
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-05-11 23:51:51
The conclusion: It is not the System Locale that is responsible for wrong ID3v1 characters but something in CUETools. But what...?

CUETools uses taglib-sharp to write tags. By default, taglib-sharp follows the ID3v1 standard and uses Latin-1 encoding for ID3v1 tags, which means that non-Latin-1 characters are replaced by '?'.
There is however an option in taglib-sharp which changes it's behaviour:
Code: [Select]
        /// <summary>
        ///    Gets and sets whether or not to use a broken behavior for
        ///    Latin-1 strings, common to ID3v1 and ID3v2 tags.
        /// </summary>
        /// <value>
        ///    <see langword="true" /> if the broken behavior is to be
        ///    used. Otherwise, <see langword="false" />.
        /// </value>
        /// <remarks>
        ///    <para>Many media players and taggers incorrectly treat
        ///    Latin-1 fields as "default encoding" fields. As such, a
        ///    tag may end up with Windows-1250 encoded text. While this
        ///    problem would be apparent when moving a file from one
        ///    computer to another, it would not be apparent on the
        ///    original machine. By setting this property to <see
        ///    langword="true" />, your program will behave like Windows
        ///    Media Player and others, who read tags with this broken
        ///    behavior.</para>
        ///    <para>Please note that TagLib# stores tag data in Unicode
        ///    formats at every possible instance to avoid these
        ///    problems in tags it has written.</para>
        /// </remarks>
        public static bool UseBrokenLatin1Behavior {
            get {return use_broken_latin1;}
            set {use_broken_latin1 = value;}
        }

However, there's currently no way for the user to set this option. I guess i could be added to advanced config in CUETools, although i agree with the authors of the above comment that it's not a desired behaviour.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-05-12 01:43:05
The offending .dll appears to be created dynamically with a different filename on each run by both CueTools and CueRipper, so you can't simply exclude the file

I just uploaded a new build of 2.1.5. Can you please check it has the same problem? I just removed CSScriptLibrary.v1.1.dll (which was probably the one causing the false-positive) from the package. So CUETools no longer supports custom scripts, which is sad but almost nobody was using them anyway.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2014-05-12 02:47:35
The download link at http://cuetools.net/wiki/CUETools_Download (http://cuetools.net/wiki/CUETools_Download) still points to the old version (the build from 2013-04-21).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-05-12 03:31:03
The download link at http://cuetools.net/wiki/CUETools_Download (http://cuetools.net/wiki/CUETools_Download) still points to the old version (the build from 2013-04-21).

Oops. Should be fixed in a few minutes, sorry about that
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-05-12 04:43:23
So CUETools no longer supports custom scripts, which is sad but almost nobody was using them anyway.

I planned to play with them but I can do that with an older version. Just to clarify, included scripts like 'repair' will still work but new user written custom scripts won't be possible. (Note: I've tested 'repair' and 'fix offset' already to verify they work).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: plugs13amp on 2014-05-12 11:50:48
The offending .dll appears to be created dynamically with a different filename on each run by both CueTools and CueRipper, so you can't simply exclude the file

I just uploaded a new build of 2.1.5. Can you please check it has the same problem? I just removed CSScriptLibrary.v1.1.dll (which was probably the one causing the false-positive) from the package. So CUETools no longer supports custom scripts, which is sad but almost nobody was using them anyway.


Yes, thats fixed it. maybe Avast will get round to sorting it one day and you can re-instate the custom scripts support, you shouldn't have had to remove functionality from your product to get round someone elses problems. If they do fix it, I'll report back.

Thanks for responding so quickly, its a great little app
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-05-12 15:41:09
Confirming that the CUETools disappearing 'offset' box issue ([a href='index.php?act=findpost&pid=800027']this post[/a], [a href='index.php?act=findpost&pid=846177']this post[/a], or bug tracker (http://sourceforge.net/p/cuetoolsnet/bugs/10/)) when changing the text size (DPI) setting in Windows appears to be fixed in the latest build of 2.1.5 dated May 11, 2014. Tested on Win7x64 at 125% (120ppi) & 150% (144ppi).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2014-05-12 17:24:38
COMMENT from CUE written to tag 'bug' still there!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thores on 2014-05-26 16:21:03
Hi!

I want to convert HDCD to 24 bit with CueTools but the process unfortunately is irreversible. This means I have to keep two versions, 16 bit and 24 bit, since I don't want to waste the accurately ripped files. This will take up twice as much space, and I have far too many HDCD's to make it worthwhile.

Hence, my question is: Isn't there a way to make a small extra file with the data needed to recreate the original file from the 24 bit version? I mean, every single bit of information in the 16 bit file is also present in the 24 bit file, only at a different location.

I assume that a program like this does not yet exist, since CueTools says the process is irreversible.

Obviously I have no programming skill, so maybe someone is willing to explain if this is possible to do?

Thore
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d125q on 2014-05-26 17:03:08
Hi!

I want to convert HDCD to 24 bit with CueTools but the process unfortunately is irreversible. This means I have to keep two versions, 16 bit and 24 bit, since I don't want to waste the accurately ripped files. This will take up twice as much space, and I have far too many HDCD's to make it worthwhile.

Hence, my question is: Isn't there a way to make a small extra file with the data needed to recreate the original file from the 24 bit version? I mean, every single bit of information in the 16 bit file is also present in the 24 bit file, only at a different location.

I assume that a program like this does not yet exist, since CueTools says the process is irreversible.

Obviously I have no programming skill, so maybe someone is willing to explain if this is possible to do?

Thore

Try using foobar2000 and foo_hdcd (http://www.foobar2000.org/components/view/foo_hdcd) to decode your HDCD material on-the-fly. This means that you won't need to convert to 24-bit at all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2014-05-26 17:06:45
You may spend some time checking how the HDCD decodes. Many only shift bit 1-16 to 2-17 without changing the audio and leave the upper 6dB unused. These are surely not worth to keep at higher bitrate.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thores on 2014-05-26 18:27:15
You may spend some time checking how the HDCD decodes. Many only shift bit 1-16 to 2-17 without changing the audio and leave the upper 6dB unused. These are surely not worth to keep at higher bitrate.

Can you determine by looking at the CueTools log which albums are worth converting to 24-bit? What should I look for? What is not important?

On the other hand, the resulting FLAC files seem to be only 10% bigger, so if I could only ditch the 16-bit files (if there was a solution to re-create them) I could do with that small increase in file size.
-
@d125q: Thanks for the suggestion. I know there are alternate ways to go but I'm looking for a solution that works on many platforms (as future proofed as possible).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2014-05-26 19:57:16
Sory, no idea how to see it with CUEtools. When i decode HDCD from command, Peak Extend is never enabled and maximum level is below -6.02dB it must be one that has no point being stored with higher bit depth.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thores on 2014-06-03 11:54:33
Would it be possible to show EAC peaks at db.cuetools.net? The same peaks are also in the CueTools log.

Quite often I am trying to figure out the remastering year and it would help to see if two different disc ID's of the same album have the same peaks - then they most probably are the same remaster. And sometimes, if one of them can be multiplied by a factor to have the same peaks as the other they would probably be the same remaster.

It's very common to re-issue an album without any remastering done to it, and the record label usually doesn't give any information on the album itself. You have to be your own detective, and CTDB could really help out with this.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bigi on 2014-06-03 15:08:19
I'm just trying to rip my 1000+ cd collection and having some problems with a few of them...even resorting to buying a JFJ Easy Pro to fix some!  In an effort to read the more "challenging" discs I've managed to get hold of a couple of 2004-2005 CD Roms Drives that are NOS.  The HP/Samsung drive is detected by CueRipper fine, but the other one gives me the "Failed to autodetect read command" error when starting the rip and just fails.  It works perfectly in EAC, but i prefer CueRipper!  Any way i can either get support added in or add it myself somehow - It's a Liteon LTN-529S?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: plugs13amp on 2014-06-27 15:40:00
The offending .dll appears to be created dynamically with a different filename on each run by both CueTools and CueRipper, so you can't simply exclude the file

I just uploaded a new build of 2.1.5. Can you please check it has the same problem? I just removed CSScriptLibrary.v1.1.dll (which was probably the one causing the false-positive) from the package. So CUETools no longer supports custom scripts, which is sad but almost nobody was using them anyway.


Yes, thats fixed it. maybe Avast will get round to sorting it one day and you can re-instate the custom scripts support, you shouldn't have had to remove functionality from your product to get round someone elses problems. If they do fix it, I'll report back.

Thanks for responding so quickly, its a great little app


Just to let you know that Avast now seems to be happy with CueTools v2.1.4  Don't know when they fixed it, been using 2.1.5, but ran the old version by mistake this morning and no complaints from Avast. So I guess the scripting can go back into .15
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lazlo Nibble on 2014-06-30 00:15:43
Would it be possible to show EAC peaks at db.cuetools.net? The same peaks are also in the CueTools log.

    Something I just noticed recently: CUETools and EAC don't calculate peak values the same way. All other things being equal, CUETools will return a peak value of 100.0 if a track contains a max sample value of +7FFF or a min sample value of -8000 -- whereas EAC returns a peak value of 100.0% if a track contains a max sample value of +7FFF or a min sample value of -8000 or -7FFF.
   
    The most common disc I've found so far that shows this difference is the South Park Bigger, Longer and Uncut soundtrack:
   
    EAC rip log (v1.0b3, but I've confirmed v0.99pb3 returns the same peaks):
   
   
Code: [Select]
     Track  1
         Filename G:\tmp\testrip2\01 The People of South Park - Mountain Town.wav
         Peak level 100.0 %
           Extraction speed 10.3 X
           Test CRC EFE9C48B
           Accurately ripped (confidence 24)  [12AB2BF3]  (AR v2)
           Copy finished
                          
       Track  2
           Filename G:\tmp\testrip2\02 Terrance & Phillip - Uncle Fucka.wav
         Peak level 100.0 %
         Extraction speed 17.7 X
         Test CRC 4AAC8A07
         Accurately ripped (confidence 24)  [C2B6672D]  (AR v2)
         Copy OK
                          
       Track  3
         Filename G:\tmp\testrip2\03 Mr Mackey - It's Easy, Mmmkay.wav
         Peak level 100.0 %
         Extraction speed 18.5 X
         Test CRC 95CF979A
         Accurately ripped (confidence 24)  [A4228687]  (AR v2)
         Copy OK

    CUETools log:
   
   
Code: [Select]
       Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
       --   99.9 [684C677E] [A4F04842]  W/O NULL
       01   99.9 [EFE9C48B] [D180B7B0]          
       02   99.9 [4AAC8A07] [8B7B00A1]          
       03   99.9 [95CF979A] [2F03A86F]
 
    Actual sample values (returned by SoX):
   
   
Code: [Select]
       Trk  Length    EACpk%   LMin  LMax   RMin  RMax  LRMSdB RRMSdB  Indicies
         T01  04:27:38  100.0%  -7FFF +7FFE  -7FFF +7FFE  -14.62 -14.86  00:00:00 00:00:32
         T02  01:06:00  100.0%  -7FFF +7FFE  -7FFF +7FFE  -12.36 -13.14  04:26:57 04:27:70
         T03  01:54:37  100.0%  -7FFF +7FFE  -7FFF +7FFE  -14.23 -14.40  05:33:17 05:33:70

    -7FFF really isn't the maximum negative value so of the two apps I think CUETools is doing the correct thing technically (100% - 1 isn't 100%), but it does call into question any comparisons between EAC-generated peak values and CUETools-generated peak values. (From what I've been able to tell they seem to agree about the difference between 99.8% and 99.9% but I haven't dug that deeply. I really wish EAC just reported max/min sample values per channel instead of boiling to down to a much-less-accurate percentage.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sorgum on 2014-07-24 12:12:03
I have a wav file and cue file created with EAC that I want to verify but I can't connect to to CTDB, I get "database access error: Forbidden.".  I've tried both 2.1.4 and 2.1.5.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-07-24 15:08:57
The only thing i can think of is you might have invalid proxy settings or something
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sorgum on 2014-07-25 18:35:10
The only thing i can think of is you might have invalid proxy settings or something


Well it was the proxy at first, that caused a timeout error, once I set the proxy correctly I get the Forbidden error.  I guess I'm the only one, it's working for everyone else?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sorgum on 2014-07-25 18:40:56
The only thing i can think of is you might have invalid proxy settings or something


Well it was the proxy at first, that caused a timeout error, once I set the proxy correctly I get the Forbidden error.  I guess I'm the only one, it's working for everyone else?


UPDATE:  Now I get: database access error: The underlying connection was closed: An unexpected error occurred on a receive.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2014-07-25 19:10:13
Works nicely here from germany.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sorgum on 2014-07-28 19:27:58
Works nicely here from germany.


So over the weekend I tried it at home, and it works there.  So as Gregory said, it's the proxy that is messing things up.  I can connect to AccurateRip just fine through the proxy, so I think there is a problem with the ctdb web site....

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: maxim7191 on 2014-08-01 00:04:22
I have an issue
There are album date in my cover art filenames.
in settings > advanced > cover art files.  I'm trying to add string "%artist% - %year% - %album%.png" I want it to accept this image for example "Muse - 2003 - Absolution.png". But it does not see the image."%artist% - %date% - %album%.png" doesn't work too.
"%artist% - %album%.png" works fine with "Muse - Absolution.png"
What template should I use for it to work with my cover art filenames?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-08-01 03:24:09
I can only find %album% and %artist% in the source code so I don't think %year% is possible for local Cover Art File search.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-08-04 21:09:41
Is there an artificial limit on how many tracks a CD must have for CUETools to see it? I have this CD (http://vgmdb.net/album/40067) which only has two tracks. CUETools doesn't see the ripped files (file browser shows folder as empty)

edit: Ah, apologies. I had a space character in one of the album's tracks tags by mistake, so CUETools saw two one-track albums -> separate files, and decided to ignore them.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-08 15:44:08
I've been successfully using CUETools 2.1.4 since it had been released, anyway I notice that version 2.1.5 is out, so I was wondering if I could upgrade to the 2.1.5 version, or it isn't stable enough?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2014-08-08 16:18:58
2.1.5 works great!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-08-08 16:29:08
2.1.5 is stable enough. I barely use 2.1.4 at all (unless I'm trying to duplicate someone's issue).
Grigory, might you consider bumping the version number and adding future fixes and improvements to 2.1.6?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-08-08 17:47:39
Ok
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-08 18:33:17
Thank you Gregory for the hard work, these are great news. I've suggested CUETools to friends and I've spread the word over the web for years, this tool really deserves some attention. Long live CUETools! Beware of the sacrilegious Medieval CUE Splitter!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-08 18:55:00
Wow. I've just noticed that, given the same conditions (same album, read first time then read again to maximize speed), the 2.1.5 version is much faster than 2.1.4 in verifying the CD rips! For example, it went from 530x to 630x! Strangely this seems to happen only with flac files, but I'm impressed nonetheless!

EDIT: I've just have a look at the changelog:

"CUETools: CUETools FLAC decoder optimized; verification now works around 50% faster when not limited by I/O"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rankxerox on 2014-08-12 09:24:35
Good morning to all of you. I have this problem with cuetools v2.1.4, from about a week:

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-08-12 11:26:09
This [a href='index.php?act=findpost&pid=865589']known problem[/a] can happen when you change the size of the text in Win7 display to something other than 'default' (under Control Panel\Hardware and Sound\Display). It was fixed in 2.1.5.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rankxerox on 2014-08-12 11:42:42
Thanks you were great and fast. It's true given that the resolution of my notebook is very push [1920x1080] with a display of 13". I ​​enlarged the characters in "Medium 125%", because even with glasses, I was struggling. Appearance then that version 2.1. 5 is operational.
Have you a good day.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-13 13:54:06
I would like to report a similar bug using version 2.1.5:

(http://i.snag.gy/4OGGM.jpg)

(http://i.snag.gy/qAQ4k.jpg)

I'm using a custom Windows text zoom set to 138%. My desktop resolution is 1920x1080.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-13 14:09:34
I've a question about the "Gaps Appended + HTOA" setting in CUETools gaps handling window. Would it be ok to always leave that setting on for every CD, or should I switch to "Gaps Appended" only, instead?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rankxerox on 2014-08-13 22:55:13
Wiki says so: (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools)

Gaps handling

    Used when encoding in Tracks mode.

Gaps Appended + HTOA {radio button}
    Recommended setting. Gaps appended to (added to end of) the previous track. Any HTOA (Hidden Track One Audio) located in the INDEX 00 (pregap) area of Track 01 will be preserved as an audio file with the track number 00 and title (HTOA).
Gaps Appended {radio button}
    Gaps appended to (added to end of) the previous track. HTOA is discarded and replaced with a PREGAP (silence) command in the CUE file.
Gaps Prepended {radio button}
    Gaps are prepended to (added to beginning of) the next track.
Gaps Left Out {radio button}
    Gaps are left out (discarded and each replaced with a PREGAP (silence) command in the CUE file).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-14 14:12:52
Wiki says so: (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools)

Gaps handling

    Used when encoding in Tracks mode.

Gaps Appended + HTOA {radio button}
    Recommended setting. Gaps appended to (added to end of) the previous track. Any HTOA (Hidden Track One Audio) located in the INDEX 00 (pregap) area of Track 01 will be preserved as an audio file with the track number 00 and title (HTOA).
Gaps Appended {radio button}
    Gaps appended to (added to end of) the previous track. HTOA is discarded and replaced with a PREGAP (silence) command in the CUE file.
Gaps Prepended {radio button}
    Gaps are prepended to (added to beginning of) the next track.
Gaps Left Out {radio button}
    Gaps are left out (discarded and each replaced with a PREGAP (silence) command in the CUE file).


You are perfectly right. I thought that I should select for each cue file:
- Gaps Appended + HTOA: when there is a hidden track.
- Gaps Appended: when there isn't a hidden track.

I thought that if I selected the first option even if there is not a hidden track, then the effect would have been the same that selecting the second option. I wanted to ask confirmation of that. So I don't have to check the cue file every time looking for a hidden track.

Anyway, I would like to report a bug. Sometimes, when I select a folder with only flac tracks (no cue file or log) and I start the verification process, CUETools checks each of them correctly, and it produces the AccurateRip report.

On the other hand, with some albums, if I still select the folder containing only the flac tracks, CUETools only checks few of them randomly. Here is a CUETools report in this case:

Code: [Select]
.\01. [Gerald Fried] Prelude.flac: AR: disk not present in database, CTDB: disk not present in database.
.\13. [Gerald Fried] Main Title.flac: AR: disk not present in database, CTDB: disk not present in database.


But, if I create a m3u file and I select it with CUETools and start the verification, everything works:

Code: [Select]
[CUETools log; Date: 14/08/2014 15:46:17; Version: 2.1.5]
[CTDB TOCID: y7hPOlW.WEUd1D_Hi6zCGNGH7w4-] found.
Track | CTDB Status
  1   | (1/1) Accurately ripped
  2   | (1/1) Accurately ripped
  3   | (1/1) Accurately ripped
  4   | (1/1) Accurately ripped
  5   | (1/1) Accurately ripped
  6   | (1/1) Accurately ripped
  7   | (1/1) Accurately ripped
  8   | (1/1) Accurately ripped
  9   | (1/1) Accurately ripped
10   | (1/1) Accurately ripped
11   | (1/1) Accurately ripped
12   | (1/1) Accurately ripped
13   | (1/1) Accurately ripped
14   | (1/1) Accurately ripped
15   | (1/1) Accurately ripped
16   | (1/1) Accurately ripped
17   | (1/1) Accurately ripped
18   | (1/1) Accurately ripped
19   | (1/1) Accurately ripped
20   | (1/1) Accurately ripped
21   | (1/1) Accurately ripped
22   | (1/1) Accurately ripped
23   | (1/1) Accurately ripped
24   | (1/1) Accurately ripped
[AccurateRip ID: 00437922-047d3144-6110fc18] found.
Track   [  CRC   |   V2   ] Status
01     [dcaeb7af|2af75dc7] (0+0/1) No match
02     [0ef1368c|cd065368] (0+0/1) No match
03     [d13f7329|425e7e65] (0+0/1) No match
04     [484c9672|d9075fec] (0+0/1) No match
05     [a7972793|319bd802] (0+0/1) No match
06     [14f2e1ca|aa275d59] (0+0/1) No match
07     [4a49051b|bcfc00a7] (0+0/1) No match
08     [7a92986c|7def9945] (0+0/1) No match
09     [f4171e81|27a2be04] (0+0/1) No match
10     [6263b810|f1890282] (0+0/1) No match
11     [91c3c922|3664ad83] (0+0/1) No match
12     [71dbf64b|cbd29285] (0+0/1) No match
13     [914e0ff4|43833b27] (0+0/1) No match
14     [756bb849|89e7b250] (0+0/1) No match
15     [2642bfed|684891fc] (0+0/1) No match
16     [3f2cef29|b7662427] (0+0/1) No match
17     [948032cc|a87047ee] (0+0/1) No match
18     [ce633150|0428ecc7] (0+0/1) No match
19     [363082ab|156b7ea4] (0+0/1) No match
20     [5bed5692|d8096990] (0+0/1) No match
21     [f1a43c69|c4bc6af9] (0+0/1) No match
22     [00e20fd1|2172a6b5] (0+0/1) No match
23     [65945161|604be3f2] (0+0/1) No match
24     [f2cc5562|e690720d] (0+0/1) No match
Offsetted by -453:
01     [772c32a3] (0/1) No match (V2 was not tested)
02     [1994b52d] (0/1) No match (V2 was not tested)
03     [e38dc188] (0/1) No match (V2 was not tested)
04     [4d97608a] (0/1) No match (V2 was not tested)
05     [b314c0bf] (0/1) No match (V2 was not tested)
06     [6d3938c6] (0/1) No match (V2 was not tested)
07     [c4b41935] (0/1) No match (V2 was not tested)
08     [4fb59586] (0/1) No match (V2 was not tested)
09     [f3fa10a3] (0/1) No match (V2 was not tested)
10     [bb3638e6] (0/1) No match (V2 was not tested)
11     [c02195d7] (0/1) No match (V2 was not tested)
12     [97c58e6b] (0/1) No match (V2 was not tested)
13     [c76a22ee] (0/1) No match (V2 was not tested)
14     [a589a21d] (0/1) No match (V2 was not tested)
15     [34fad3ef] (0/1) No match (V2 was not tested)
16     [693dfe6b] (0/1) No match (V2 was not tested)
17     [e2f38bf0] (0/1) No match (V2 was not tested)
18     [5e097194] (0/1) No match (V2 was not tested)
19     [655d3f9b] (0/1) No match (V2 was not tested)
20     [af75300d] (0/1) No match (V2 was not tested)
21     [38970804] (0/1) No match (V2 was not tested)
22     [1491d810] (0/1) No match (V2 was not tested)
23     [254c254c] (0/1) No match (V2 was not tested)
24     [bc0b2200] (0/1) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL]
--  100,0 [FFDB895D] [A6AD92A1]          
01   94,6 [8A534AA1] [0760DF2C]          
02   67,8 [40CA3A1A] [84489CD5]          
03   84,1 [E88B2DA8] [E38E7D78]          
04   94,6 [8908DAAC] [C51BB221]          
05   94,9 [72CBF60F] [F03DCA74]          
06   95,4 [01C68573] [3579D1FB]          
07   62,0 [55EE4CC4] [115F2AC2]          
08   94,6 [CA605B00] [BE2E3D9F]          
09   68,1 [42CDB836] [C6DAAF75]          
10   79,2 [5886FAE7] [F1B3CB4D]          
11   84,3 [0A77DEF4] [84FC31F0]          
12   84,3 [57173E55] [47AEB22E]          
13   94,6 [90698436] [4EFEF1C3]          
14   94,6 [9CB7FD0F] [9D3E8095]          
15   94,6 [8EA122FD] [5203BD08]          
16   94,6 [E9C9491B] [6EC7D08D]          
17   94,6 [F3E8DA13] [368E97FB]          
18   93,1 [19D72492] [12844A4F]          
19   59,1 [A4756A91] [A5863815]          
20   94,6 [65A23E61] [43D5A898]          
21   69,3 [D0332306] [039C8F82]          
22  100,0 [1B0CB01C] [2115933B]          
23   61,3 [69BB7539] [08994292]          
24   61,3 [983C36AA] [CE11818E]


If there is a solution for this, so that it would be sufficient to select the folder containing the tracks for a simple verification, it would be greatly appreciated.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-08-14 15:14:41
That usually happens when the album tag is not the same for all files in the folder. Check for trailing/double spaces etc.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-14 22:26:03
That usually happens when the album tag is not the same for all files in the folder. Check for trailing/double spaces etc.


Like you said, in my case I wrongly tagged some albums, which had to be:

Code: [Select]
CD 1:

01 - batman - title 1
02 - batman - title 2
03 - batman returns - title 1
04 - batman returns - title 2


But it erroneously was:

Code: [Select]
CD 1:

01 - batman - title 1
02 - batman - title 2
01 - batman returns - title 1
02 - batman returns - title 2


So it was like the single CD were 2 CDs, instead. Correctly tagging the traks solved the problem.

I'm still curious to know if a default choice of appended gaps + htoa for each album would work, though. Has someone been doing that?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-08-14 22:46:25
I thought that if I selected the first option even if there is not a hidden track, then the effect would have been the same that selecting the second option. I wanted to ask confirmation of that. So I don't have to check the cue file every time looking for a hidden track.

With the first option, if there is any gap located in the INDEX 00 (pregap) area of Track 01 it will be preserved as an audio file with the track number 00 and title (HTOA). Even if it is just 32 frames of silence. So HTOA is NEVER discarded and replaced with a PREGAP (silence) command in the CUE file.
An actual hidden track is longer than a few seconds. I still wish there was a way to only save as an audio file if the duration was longer than a few seconds.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-15 02:41:43
I thought that if I selected the first option even if there is not a hidden track, then the effect would have been the same that selecting the second option. I wanted to ask confirmation of that. So I don't have to check the cue file every time looking for a hidden track.

With the first option, if there is any gap located in the INDEX 00 (pregap) area of Track 01 it will be preserved as an audio file with the track number 00 and title (HTOA). Even if it is just 32 frames of silence. So HTOA is NEVER discarded and replaced with a PREGAP (silence) command in the CUE file.
An actual hidden track is longer than a few seconds. I still wish there was a way to only save as an audio file if the duration was longer than a few seconds.


Finally I've understood the point, thank you. Well, your suggestion about the hidden track duration detection is valuable, tough.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2014-08-16 04:45:21
I've another question regarding CUETools verification. Do you think that my rip is problematic on track 13, even if test & copy crc are the same?:

Code: [Select]
[CUETools log; Date: 16/08/2014 05:38:02; Version: 2.1.5]
Offset applied: 667
[CTDB TOCID: zlIUqg46NkG9s4NNAGoXo6O8R8c-] found.
Track | CTDB Status
  1   | (10/11) Accurately ripped
  2   | (10/11) Accurately ripped
  3   | (11/11) Accurately ripped
  4   | (10/11) Accurately ripped
  5   | (11/11) Accurately ripped
  6   | (11/11) Accurately ripped
  7   | (11/11) Accurately ripped
  8   | (11/11) Accurately ripped
  9   | (11/11) Accurately ripped
10   | (11/11) Accurately ripped
11   | (11/11) Accurately ripped
12   | (11/11) Accurately ripped
13   | ( 7/11) Differs in 2 samples @01:11:61
14   | (11/11) Accurately ripped
15   | (10/11) Accurately ripped
16   | (11/11) Accurately ripped
[AccurateRip ID: 00251c2a-01c118ff-db0fe810] found.
Track   [  CRC   |   V2   ] Status
01     [a7c299f8|e127ce0b] (19+06/59) Accurately ripped
02     [079a6a1e|bb2b5ba6] (18+07/60) Accurately ripped
03     [0b3026a2|1ba03a20] (19+07/61) Accurately ripped
04     [444829c9|dd3feb7f] (19+07/61) Accurately ripped
05     [45b191e3|cb11bf06] (19+07/61) Accurately ripped
06     [864d663b|c7dd9192] (19+07/61) Accurately ripped
07     [92ac9917|dc1f8ec3] (19+07/61) Accurately ripped
08     [12e37362|059bff53] (19+07/61) Accurately ripped
09     [0a6c7387|b0cb2267] (19+07/61) Accurately ripped
10     [51aadb93|a1c45796] (19+07/60) Accurately ripped
11     [cbba35e7|962ec6d0] (19+07/61) Accurately ripped
12     [73748212|924344f3] (18+07/60) Accurately ripped
13     [92dabf2a|1f97fe6d] (00+00/61) No match
14     [f1f14090|9d402e83] (19+07/60) Accurately ripped
15     [55509095|584e2df1] (19+07/58) Accurately ripped
16     [c2384c52|ed4f6c4a] (19+07/58) Accurately ripped
Offsetted by 845:
01     [83cafc62] (11/59) Accurately ripped
02     [a292acbb] (11/60) Accurately ripped
03     [3f5a9bc0] (11/61) Accurately ripped
04     [eac83fb6] (11/61) Accurately ripped
05     [51925946] (11/61) Accurately ripped
06     [5dfbdf9b] (11/61) Accurately ripped
07     [8ff9fb72] (11/61) Accurately ripped
08     [4b1ee8c6] (11/61) Accurately ripped
09     [00673080] (11/61) Accurately ripped
10     [e0a125cb] (11/60) Accurately ripped
11     [9dfa7beb] (11/61) Accurately ripped
12     [21bccf5d] (11/60) Accurately ripped
13     [34aeff8b] (00/61) No match (V2 was not tested)
14     [a9afa9a4] (11/60) Accurately ripped
15     [a811c131] (11/58) Accurately ripped
16     [53d6dc03] (10/58) Accurately ripped
Offsetted by 885:
01     [716d7732] (00/59) No match (V2 was not tested)
02     [1a00e363] (05/60) Accurately ripped
03     [cbab6330] (05/61) Accurately ripped
04     [e2004cde] (05/61) Accurately ripped
05     [62cbf29e] (05/61) Accurately ripped
06     [4e71329b] (05/61) Accurately ripped
07     [28d7c68a] (05/61) Accurately ripped
08     [efdd8ee6] (05/61) Accurately ripped
09     [68730f08] (05/61) Accurately ripped
10     [3f41418b] (04/60) Accurately ripped
11     [746d9f0b] (05/61) Accurately ripped
12     [2d0465f5] (05/60) Accurately ripped
13     [5310e753] (00/61) No match (V2 was not tested)
14     [dfd3f144] (05/60) Accurately ripped
15     [38dccb11] (04/58) Accurately ripped
16     [77837a4b] (05/58) Accurately ripped
Offsetted by 947:
01     [2e8fb58e] (12/59) Accurately ripped
02     [86521e81] (12/60) Accurately ripped
03     [985bcb84] (12/61) Accurately ripped
04     [1463fadc] (12/61) Accurately ripped
05     [3d7ed380] (12/61) Accurately ripped
06     [c3270cdb] (12/61) Accurately ripped
07     [55c927bc] (12/61) Accurately ripped
08     [159ea9fe] (12/61) Accurately ripped
09     [e352418e] (12/61) Accurately ripped
10     [eb86395b] (12/60) Accurately ripped
11     [b4067be3] (12/61) Accurately ripped
12     [8b4cf5c7] (12/60) Accurately ripped
13     [dbc241c9] (00/61) No match (V2 was not tested)
14     [e6f2937c] (12/60) Accurately ripped
15     [594ab3f9] (12/58) Accurately ripped
16     [d5356fa1] (12/58) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   94,4 [623D4CCE] [1FD3F42B]          
01   87,4 [5C9B8222] [5EACB604]  W/O NULL
02   82,8 [90DAB5A3] [99A90332]  W/O NULL
03   64,8 [D34AD169] [93810CB1]  W/O NULL
04   84,5 [FF171F84] [ED51E319]  W/O NULL
05   74,0 [F3598071] [5FFD576E]  W/O NULL
06   94,4 [CF5611F1] [95645CB4]  W/O NULL
07   75,6 [A1F68180] [13FB1808]  W/O NULL
08   72,5 [C2F9F3C3] [4C65F902]  W/O NULL
09   79,1 [69227F75] [2A105CDB]  W/O NULL
10   80,9 [7751527E] [01406D82]  W/O NULL
11   55,7 [AC17973B] [806A90FA]  W/O NULL
12   74,6 [B3DA3DFF] [05937ADC]  W/O NULL
13   74,0 [7AAE00EA] [264AA6DB]  W/O NULL
14   85,7 [F3BBE844] [030CF5A4]  W/O NULL
15   67,5 [B854CE02] [95831CEC]  W/O NULL
16   87,1 [5CCC8CC8] [C6773305]  W/O NULL
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BrassDude on 2014-08-16 08:46:57
I recently updated to CUETools 2.1.5 since it is now the latest stable version. When I do a verification of a FLAC file I'm writing out a file with the format:

%music%\%albumartist%\%album% - %date% - %sourceformat%\%albumartist% - %album% - %date% - %sourceformat%$ifgreater(%totaldiscs%,1,[ - %discnumber%],).riplog

Under version 2.1.4 the %date% field gets properly taken from the FLAC file but in version 2.1.5 just the string %date% is written out. The other fields seem to work normally.

Did this change in 2.1.5 or is this a bug? If not, what is the correct way to get the %date% (actually I just have the year in that field) in version 2.1.5?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-08-16 14:14:58
Try %year% - http://www.cuetools.net/wiki/Cuetools_templates (http://www.cuetools.net/wiki/Cuetools_templates)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-08-16 15:17:35
I've another question regarding CUETools verification. Do you think that my rip is problematic on track 13, even if test & copy crc are the same?:

Code: [Select]
[CUETools log; Date: 16/08/2014 05:38:02; Version: 2.1.5]
Offset applied: 667
[CTDB TOCID: zlIUqg46NkG9s4NNAGoXo6O8R8c-] found.
Track | CTDB Status
  1   | (10/11) Accurately ripped
  2   | (10/11) Accurately ripped
  3   | (11/11) Accurately ripped
  4   | (10/11) Accurately ripped
  5   | (11/11) Accurately ripped
  6   | (11/11) Accurately ripped
  7   | (11/11) Accurately ripped
  8   | (11/11) Accurately ripped
  9   | (11/11) Accurately ripped
10   | (11/11) Accurately ripped
11   | (11/11) Accurately ripped
12   | (11/11) Accurately ripped
13   | ( 7/11) Differs in 2 samples @01:11:61
14   | (11/11) Accurately ripped
15   | (10/11) Accurately ripped
16   | (11/11) Accurately ripped
...

What I'm getting from this is that if you repair your rip with cuetools, you will get confidence 7/11 on that track. Currently it's seeing your rip as not accurate.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BrassDude on 2014-08-17 18:03:21
Try %year% - http://www.cuetools.net/wiki/Cuetools_templates (http://www.cuetools.net/wiki/Cuetools_templates)


Thanks korth - that worked!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2014-08-18 02:41:49
Hi,

I just noticed CUEtools have moved to Mercurial. Damn. ;-)

So I just wanted to update German translations but it says I have no permission anymore?

Anyway...
Here's the update. Hope I haven't missed a thing.

https://www.dropbox.com/s/d659cdsct8uv6do/548.patch (https://www.dropbox.com/s/d659cdsct8uv6do/548.patch)

Regards.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: audiophool on 2014-08-18 16:58:42
Will the EAC plugin see an update to 2.1.5 as well?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-08-18 17:18:46
Hi,
I just noticed CUEtools have moved to Mercurial. Damn. ;-)

So I just wanted to update German translations but it says I have no permission anymore?

Oops. Apparently sourceforge reset user permissions when upgrading the project to a new platform.  This is not fixed, and i will apply your patch when i get a minute. Thank you!

UPD: i meant to say this is *now* fixed
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-08-18 17:20:59
Will the EAC plugin see an update to 2.1.5 as well?

There weren't any significant changes to the EAC plugin since 2.1.4; Unfortunately, EAC itself hasn't been updated for a long time and it still comes with an even older version bundled.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 2014-08-18 17:36:37
Apparently sourceforge reset user permissions when upgrading the project to a new platform.  This is not fixed, and i will apply your patch when i get a minute. Thank you!


Thank you too. I'll keep an eye on it!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: audiophool on 2014-08-18 17:56:50
There weren't any significant changes to the EAC plugin since 2.1.4

Thanks for confirming that! (It wasn't quite clear to me from looking at the changelog.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2014-08-23 15:30:31
Any changes to the changelog now when v2.1.5 is the current stable version?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-08-23 19:02:15
No changes that I can think of that made it stable.
The only significant change that isn't listed in the changelog was the [a href='index.php?act=findpost&pid=865548']removal of references to the CSScriptLibrary.v1.1.dll[/a] which removes the ability for the user to add custom scripts.
There were some minor fixes which can be listed as "Various bug fixes".
I'll make adjustments to the wiki. I've already removed other references to the Scripts tab from the wiki.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2014-08-23 19:12:28
Thnx for the reply/info korth.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2014-09-01 14:12:20
For metadata lookups, how does CUERipper find a given CD in Discogs? Does it require that the disc have an entry and relationships data in MusicBrainz, or what?

Is CUERipper affected by the recent Discogs API changes? In Mp3tag, to do a Discogs lookup, you now have to have a Discogs account which you authorize access to; Discogs gives you an OAuth token that copy-paste back into Mp3tag. I also saw something about them ditching XML and switching to JSON. It may just be buggy at the moment, though: http://forums.mp3tag.de/index.php?showtopi...amp;#entry79121 (http://forums.mp3tag.de/index.php?showtopic=18846&st=15&p=79121&#entry79121)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-09-01 15:48:21
Unless things have changed, CUERipper gets the metadata from the CTDB. CTDB replicates and stores the data from Discogs. Discogs searches can be done using a fuzzy search algorithm or associations via a Musicbrainz discid search. The metadata search setting in CUERipper (http://www.cuetools.net/wiki/CUERipper_Options) will determine which searches are used.

I'll leave the rest for Grigory (and any corrections to the above as needed).

Edit: spelling correction
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: gojirasan on 2014-09-08 20:55:54
I am writing a script to convert audio books to wavs/mp3s quickly and without using the analog hole and the console version of cueripper seems perfect for the tool chain (and it is also the only console ripper that runs in windows natively) except that there is no documentation at all for using the console version.  So I will ask my questions here. I do plan to post my tool here when I am finished btw.

Questions:

1) CTDB searching. Is there a way to stop cuetools.consoleripper.exe from searching databases like CTDB, Brainz, and Accuraterip for data? For audio books this is not helpful and it seems to match up with music CDs and then I end up with filenames based on some random music CD. I noticed that when I run the cueripper.exe or cuetools.exe it makes a folder for itself and writes a settings.txt file in that folder. Settings.txt for cuetools.exe is the most complete and has some interesting sounding settings. I have tried messing with both files and copying settings from the cuetools settings.txt file to the cueripper one just in case cuetools.consoleripper.exe actually just calls cueripper.exe or something like that.

FWIW here are some of the settings from the cuetools settings.txt that seem like they could be useful to me:

CUEToolsDBLookup=0
MusicBrainzLookup=0
AccurateRipLookup=0
LocalDBLookup=0
KeepOriginalFilenames=1
AccurateRipMode=0
DontGenerate=1
AutoCorrectFilenames=0

Advanced=<CUEConfigAdvanced>
=<CTDBSubmit>false</CTDBSubmit>
=  <CTDBAsk>false</CTDBAsk>
=  <metadataSearch>None</metadataSearch>
=</CUEConfigAdvanced>

I don't think cuetools.consoleripper.exe is reading either of those settings.txt files. It does not seem to matter what changes I make to them. Is this in fact the case? Is cuetools.consoleripper.exe intended to read a settings.txt file as well? If so where should I put it? Can I just copy a settings.txt file from the cuetools or cueripper folder to somewhere where cuetools.consoleripper.exe will look for it?

2) Rips to a single wav (cdimage.wav). The program that I just wrote takes multiple files named "Track<nn>.wav" as inputs and there are good reasons for that. I suppose I could try to split the wav up again using the cue file, but since this is supposed to be an automated script that presents all sorts of difficulties. acdir, sox, and shntool are all windows command line tools that can resplit the file or I could even write my own, but it would be a lot better if that were not necessary.

3) Save-To Folder. Is there a way to tell cuetools.consoleripper.exe where to rip the files? Currently it just puts cdimage.exe and a cdimage.cue in the cuetools folder itself. This is not that big of a deal except that I would like others to be able to use my script and they probably don't have  a "P:" drive letter or put their programs in the same place I do. I suppose I could put cuetools.consoleripper.exe at "c:\" and search for the files there, but that is obviously less than ideal.

If it is not possible to change the default behavior of cuetools.consoleripper.exe then I'd like to look into how difficult it might be to alter the C# source code. Maybe it is as easy as just commenting out the CTDB checks etc. I am not familiar with C# though. So I would have to read some books on it which I eventually wanted to do anyway I guess. I went to the sourceforge page with the source code and I noticed there are a lot of files there. Aside from the obvious "CUETools.Ripper.Console" folder what other folders should I be downloading to examine the source if I want to change the above behavior in cuetools.consoleripper.exe?

I would certainly be grateful if the program author or anyone else can tell me how to do these things or whether they are just hard coded in the console version. In which case I would appreciate any help in finding which .cs files from the project I should be examining. I do plan to use cuetools.consoleripper.exe in my script no matter what even if I have to live with the current default behavior, but it would certainly be nice if I could change it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-09-09 00:20:20
See the second part of [a href='index.php?act=findpost&pid=771411']this post[/a].

CUETools.ConsoleRipper.exe appears to be dependent on
plugins\CUETools.Ripper.SCSI.dll
CUETools.Ripper.dll
CUETools.Codecs.dll
CUETools.CDImage.dll
CUETools.AccurateRip.dll
CUETools.CTDB.dll
CUETools.ConsoleRipper.exe.config

You are correct, it does not appear to be dependent on any CUERipper settings and writes CDImage only.

Destination of the files depends on where you call CUETools.ConsoleRipper.exe from. For example:
If I start the app from C:\Users\ME in the command prompt
C:\Users\ME>"C:\AudTools\CUETools_2.1.5\CUETools.ConsoleRipper.exe" -S -D D:
the files are written to C:\Users\ME

Have a look at CUETools.Ripper.Console/Program.cs (http://sourceforge.net/p/cuetoolsnet/code/ci/default/tree/CUETools.Ripper.Console/Program.cs)

Edit: CUETools.ConsoleRipper.exe.config just tells it to also look in the plugins folder
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: gojirasan on 2014-09-09 03:37:45
I just realized that maybe the CTDB thing doesn't matter if it is just going to write to a single cdimage.wav every time anyway. Hopefully splitting the wav won't be a problem with 3 different command line tools for the job.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: aarcane on 2014-09-17 19:37:41
Heya all, I just started using cuetools again, and trying out cue ripper.  There's one feature I noticed and would like to suggest an improvement to, and another feature I'd like to suggest since I can't find it anywhere in cueripper.

Firstly, secure ripping mode.  I notice that it reads the cd twice at least, and compares the two copies.  It then compares the checksums to the accuraterip database at some point to verify further.  What I don't understand is why it seems to read the cd in 1 minute chunks twice before moving on?  Wouldn't it be more efficient and less wear on the drive to read the whole disk twice linearly instead of in small chunks like that?  Is there a good reason why it was set up the way it is?  It seems like such a small chunk size should be reserved for a more secure ripping mode?  Can this be either added or made configurable in a future release?

Secondly, cuetools has a cool feature to add accuraterip tags to the cuesheet and flac file.  I couldn't find this option in the cueripper, even though it was clearly doing the verification process.  Can this be added to cueripper?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-09-17 23:00:02
See this article on secure ripping (http://wiki.hydrogenaud.io/index.php?title=Secure_ripping). What you describe is more like burst mode test & copy.
Some rippers now can do a single burst rip + AccurateRip check and rereads only if no AccurateRip matches. I would prefer this be added to CUERipper.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: aarcane on 2014-09-22 02:57:40
See this article on secure ripping (http://wiki.hydrogenaud.io/index.php?title=Secure_ripping). What you describe is more like burst mode test & copy.

Thank you korth, that answered the first question for me perfectly.  I'm doing that as we speak.

Some rippers now can do a single burst rip + AccurateRip check and rereads only if no AccurateRip matches. I would prefer this be added to CUERipper.

I would totally +1 this request!  It seems like what I had to do manually to rip a Gummibär album, which unfortunately was surprisingly absent from the Database.

I would like to add another small request, and two minor complaint/annoyance bug reports:

CueRipper seems to be missing GD3 support.  GD3 is a nice database service that I actually paid for a while back.  EAC supports it, as well as a few other apps.  It provides quite nice metadata as well as high resolution album art scans, so adding it to cueripper and cuetools would be nice.

Secondly, Album Art.  The way it works is a little fudgy, and I couldn't find a way to "browse for album art".  I suggest that the album art pane should be pre-populated with a stock "No Album Art Available" image to make it clear what it is to first-time users, and that clicking on it should pull up a dialog to let you click on one of the available album arts, or to browse to select your own.

The last and final annoyance/bug report revolves around ReplayGain and SoundCheck support.  This one is two-part.  Firstly, Because I couldn't find any documentation to add ReplayGain tags to a rip or an encode in cue* anywhere, I fired up fb2k to add them to my final flac files.  When converting from these flac files to aac files, the resultant files had neither ReplayGain nor SoundCheck tags in them.  It would be nice if ReplayGain in the cuesheet would be preserved when transcoding, and especially helpful if soundcheck tags could be added to appropriate formats when one is selected as output, especially .mp3 and .m4a, but also possibly .wav and .aiff.

I know I've written a lot here, but I hope you'll consider what I've said and I hope you'll implement some or all of it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-09-22 06:03:15
Quote
CueRipper seems to be missing GD3 support.

Just a note. CUETools and CUERipper currently get metadata and cover art from the CTDB (http://www.cuetools.net/wiki/CUETools_Database). The CTDB retrieves that data from other free databases. Using a pay service couldn't be handled the same way.

Quote
Secondly, Album Art. The way it works is a little fudgy, and I couldn't find a way to "browse for album art".

I haven't updated the wiki (http://www.cuetools.net/wiki/CUERipper_Settings#.2819.29_Album_Art_preview) to show all the changes in 2.1.5 yet. Right now it does say to hover and click to change the image. It doesn't say that the cover art can change when you select to use different metadata. Having a blank image won't show you the art associated with each selection. It doesn't say that if you have the Album Art search set to 'Large', right-clicking the mouse pointer over the image will show a section of the image at full size. It also doesn't say that if you set Metadata search to 'Extensive', you may get more cover art images along with the additional metadata.

Quote
When converting from these flac files to aac files, the resultant files had neither ReplayGain nor SoundCheck tags in them. It would be nice if ReplayGain in the cuesheet would be preserved when transcoding,

I haven't checked SoundCheck tags (no iTunes) but do you have Copy unknown tags (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging) checked. This is needed to copy ReplayGain tags to the files when converting with CUETools. I just ran a test FLAC to AAC with fb2k applied ReplayGain tags plus CUE sheet REM entries (such as REM REPLAYGAIN_TRACK_GAIN +2.02 dB) and everything copied to the output CUE sheet and AAC files just fine.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: aarcane on 2014-09-22 11:07:19
Quote
CueRipper seems to be missing GD3 support.

Just a note. CUETools and CUERipper currently get metadata and cover art from the CTDB (http://www.cuetools.net/wiki/CUETools_Database). The CTDB retrieves that data from other free databases. Using a pay service couldn't be handled the same way.

It seems to have MusicBrainz and freedb available as well..  Or are those by proxy from ctdb?

Quote
Secondly, Album Art. The way it works is a little fudgy, and I couldn't find a way to "browse for album art".

I haven't updated the wiki (http://www.cuetools.net/wiki/CUERipper_Settings#.2819.29_Album_Art_preview) to show all the changes in 2.1.5 yet. Right now it does say to hover and click to change the image. It doesn't say that the cover art can change when you select to use different metadata. Having a blank image won't show you the art associated with each selection. It doesn't say that if you have the Album Art search set to 'Large', right-clicking the mouse pointer over the image will show a section of the image at full size. It also doesn't say that if you set Metadata search to 'Extensive', you may get more cover art images along with the additional metadata.

I've had to browse google manually for the album art for one of my albums.  I don't remember which.  I then had to rename it appropriately, and I had to place it in the rips folder for cuetools to pick it up.  That was annoying, and a simple "click -> browse" in cue ripper would have been handy.
Does large album art automatically fall back to medium or small album art if large is unavailable, or does it only search for Large?

Quote
When converting from these flac files to aac files, the resultant files had neither ReplayGain nor SoundCheck tags in them. It would be nice if ReplayGain in the cuesheet would be preserved when transcoding,

I haven't checked SoundCheck tags (no iTunes) but do you have Copy unknown tags (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Tagging) checked. This is needed to copy ReplayGain tags to the files when converting with CUETools. I just ran a test FLAC to AAC with fb2k applied ReplayGain tags plus CUE sheet REM entries (such as REM REPLAYGAIN_TRACK_GAIN +2.02 dB) and everything copied to the output CUE sheet and AAC files just fine.

I just did the exact same test, but I'm ripping to single FLAC with embedded CUEsheet.  The resultant .m4a files do NOT have replaygain tracks.  I double-checked by deleting an album, verifying that "Copy Unknown Tags" is checked (everything in that box is checked), then reconverting.  The end result was m4a files with essentially every other tag in place, but no replaygain tags in the tracks as per aimp.  It does, however, have album and track gain tags in the cuesheet in the resultant folder, which is promising.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-09-22 14:21:02
Quote
It seems to have MusicBrainz and freedb available as well.. Or are those by proxy from ctdb?

The metadata is replicated and stored in the CTDB.

Quote
Does large album art automatically fall back to medium or small album art if large is unavailable, or does it only search for Large?

If a 150px thumb is all that's available then that's what you get.

Quote
I just did the exact same test, but I'm ripping to single FLAC with embedded CUEsheet. The resultant .m4a files do NOT have replaygain tracks.

OK I see now what you're saying. For Image+CUE or embedded CUE, fb2k only writes replaygain info to the CUE. When converting Image+CUE or embedded CUE in CUETools to tracks, replaygain info is still written to the CUE but not copied to the tags of the track files. Currently CUETools only adds basic tags from CUE data.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-10-01 18:59:14
Would it be possible to somehow change the tagging window on CUETools so that pressing the home key does NOT jump to the (uneditable) label of the row and just jump to the start of the edit field as it should?
It's kind of frustrating having to manually navigate the cursor to the start of the entry instead of pressing "home" and be done with it.


Current behavior:
Code: [Select]
#1 | Track01][   -> "home" -> [#1] | Track01


Desired behavior:
Code: [Select]
#1 | Track01][   -> "home" -> #1 | ][Track01


(with ][ being the text cursor, [] highlight of the label)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-10-04 22:26:16
Another thing: if you put the files for verification into an NTFS drive root (e.g. a RAM disk), CUETools will fail to do anything because
Code: [Select]
Access to the path 'R:\System Volume Information' is denied..


Why is it going there in the first place? I have "try to locate missing files" enabled, but in this case I am selecting the files, not the .cue, and even for correct cuesheets, CUETools still seems to be traversing folders unnecessarily.

Adding certain system folders (like the system volume information) to an internal blacklist should make sense.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: aarcane on 2014-10-13 02:54:38
I've discovered another small bug using the opus codec.  The opus codec goes into a file with .opus as the extension, but the container is simply a standard ogg container.  Therefore, taglib/ogg should be used to add tags, however, taglib is attempting to use taglib/opus, which is not defined.  Other than the present inability to tag .opus files, the opus container seems to work simply by pointing the encoder at opustools.  This is occuring as of cuetools 2.1.5.  Opus tools is available from here:  http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) and I used the following settings to configure opus encoding:

add format:  Opus
select opusenc vbr
select lossy encoding

add encoder: extension opus
Path: opus-tools-0.1.9-win32\opusenc.exe
parameters: --vbr - %O
Modes:  <Empty>
Name:  opusenc vbr

I added an opusenc cvbr as well as follows, but didn't use it:
add encoder: extension opus
Path: opus-tools-0.1.9-win32\opusenc.exe
parameters: --cvbr %M - %O
modes: 6 24 32 48 64 96 112 128 160 256 510
Name: opusenc cvbr
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: aarcane on 2014-10-13 04:40:53
Just found another small..  mis-feature in cueripper.  I can't find a button to say "None of these metadata options is correct.  Treat it as a blank album".  I had to manually enter metadata for an album for which the only reasonable track titles are "Track 01", "Track 02", ... "Track 99".  It was mis-identified as any of a half dozen other audio books.  Therefore, I had to manually enter those track titles for 99 books.  A simple button which says "None of these is right, Reset it to a blank album" which also renumbers the tracks as above would have been quite useful.  If it is present, I couldn't find it anywhere.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: aarcane on 2014-10-13 08:31:42
Just found another small..  mis-feature in cueripper.  I can't find a button to say "None of these metadata options is correct.  Treat it as a blank album".  I had to manually enter metadata for an album for which the only reasonable track titles are "Track 01", "Track 02", ... "Track 99".  It was mis-identified as any of a half dozen other audio books.  Therefore, I had to manually enter those track titles for 99 books.  A simple button which says "None of these is right, Reset it to a blank album" which also renumbers the tracks as above would have been quite useful.  If it is present, I couldn't find it anywhere.

A workaround is to start the rip, stop the rip, then use a robust text-editor to edit the newest xml file in the folder %APPDATA%/CUE Tools/MetadataCache (Make sure it's the correct file) to perform a quick global search/replace for "wrong" information.  Carefully.  Then simply eject and re-load the disk, and it'll pick up the correct data.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2014-10-23 08:57:59
Hello, i have a problem in CueTools with this message:
Exception: Build failed with error code BUILD_PROGRAM_FAILURE

half month ago i have no that problem, and convert files without any problems. I read topics about that problem, but didn't found solutions.

My system:
CueTools 2.1.5 from official web site

OS: Windows 8.1 64bit Single Language with all Updates
Proc: Intel Core i3 4130
MB: GigaByte B85M-D3H - Bios Up to Date
Mem: GEIL 8192 МБ DDR3 PC3-12800 (800 МГц)
VideoCard: Zotac GeForce nVidia GTS 250 512 MB
SSD: SanDisk SDSSDHP128G
HDD: WDC WD10EALX-229BA0

PS: Let me know which information u need to help to solve this problem.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-10-23 13:13:57
Grigory will be of more help on this than I but I believe this is from the FlacCL encoder.
Some more info to help him:
Same build of CUETools and plugins?
Any recent changes to computer? Updates? Drivers?
You're Converting using same encoder as when you had no problems?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2014-10-23 13:50:57
Hello, i have a problem in CueTools with this message:
Exception: Build failed with error code BUILD_PROGRAM_FAILURE

If you really have the problem with flacCL there may have been a small change lately that kicked out your GTS 250.
You may try to test flacCL with your Intel Core i3 4130 build in HD graphics if the problem is solved.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2014-10-23 16:58:14
Grigory will be of more help on this than I but I believe this is from the FlacCL encoder.
Some more info to help him:
Same build of CUETools and plugins?
Any recent changes to computer? Updates? Drivers?
You're Converting using same encoder as when you had no problems?

i clear all information about cuetools (it self directory and AppData\Roaming\coetools)
then download current (2.1.5) version from this URL: http://cuetools.net/wiki/CUETools_Download (http://cuetools.net/wiki/CUETools_Download)
extract it, change Audio Output to "Lossless", Flac, FlacCL. In settings at Platform i have 3 various:
Intel® OpenCL - Exception: no OpenCL devices found that matched filter criteria
Experimental OpenCL 2.0 CPU Only Platform - Exception: no OpenCL devices found that matched filter criteria
and NVIDIA CUDA - Exception: Build failed with error code BUILD_PROGRAM_FAILURE

PS: Drivers for NVIDIA, i tried latest drivers 340.52 and 337.88 older one, cuz i remember that i was update them. Drivers for Intel, i have installed "Intel Graphic Driver", "OpenCL runtime for Intel Core and Xeon Processor, and Intel Xeon Phi coprocessors" and "Intel SDK for OpenCL Applications 2014" just in case biggrin.gif

All 3 platforms has worked before changes, but which one could broke it i have no idea.
Some changes i remember:
Update:
Windows
Mozilla FireFox 33.0 (x86 ru)
Mozilla ThinderBird 31.2.0 (x86 ru)
K-Lite Mega Codec Pack to 10.8.0
nVidia Driver to 340.52, then 337.88
Java 7 to update 71

Checked system for Viruses by:
DrWeb Cure It
Kaspersky Virus Removal Tool
Kaspersky Security Scan
AVZ
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2014-10-23 17:29:12
Most likely the same problem here: http://www.hydrogenaud.io/forums/index.php...4628&st=375 (http://www.hydrogenaud.io/forums/index.php?showtopic=64628&st=375)
Your Gts250 may report OpenCL 1.0 only while it can do 1.1 As i understand editing the flac.cl file can work with removing the OpenCL version check.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2014-10-23 18:17:31
How exactly i could disable OpenCL Version Check? (i am not a programmer)

any way i cant understand why other two methods was broken too
Intel® OpenCL - Exception: no OpenCL devices found that matched filter criteria
Experimental OpenCL 2.0 CPU Only Platform - Exception: no OpenCL devices found that matched filter criteria
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2014-10-24 22:48:22
And i have a problem with compressing to qaac. Average speed in CueTools is near 47x but Foobar2000 could convert with 115x. Foobar use 4 qaac processes, CueTools use only one.

I have check on "Separate thread for decoding"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2014-11-01 13:38:48
Anyone..? Anything...?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2014-11-02 07:28:13
Then it probably just doesn't support multiple encoding-threads.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2014-11-02 11:11:29
I guess so, that is just a feedback. What about my problem which I ask earlier?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: edwardar on 2014-11-10 00:00:00
Most likely the same problem here: http://www.hydrogenaud.io/forums/index.php...4628&st=375 (http://www.hydrogenaud.io/forums/index.php?showtopic=64628&st=375)
Your Gts250 may report OpenCL 1.0 only while it can do 1.1 As i understand editing the flac.cl file can work with removing the OpenCL version check.


I have the same problem on my nVidia GT8600, although I have just found a way to 'fix' it:

If I use flac.cl from an old version of cuetools (the last version that worked with FLACCL), it creates a metainfo.xml file in "C:\Documents and Settings\myusername\Local Settings\Application Data\CUE Tools\OpenCL" along with a data file.

Once these files are created, then latest version works perfectly (without any modification or replacing files).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Groxxxy on 2014-11-19 16:32:23
I'm using CueTools through PlayOnLinux trying to access a USB connected drive but I get the message "The given path's format is not supported".
I cannot keep my library on my internal drive so I want to run CueTools on my external but I can't. How come?

(http://i.imgur.com/bbFZXRW.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-11-19 16:35:53
Honestly, didn't even know it works with PlayOnLinux
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-11-19 18:39:51
Honestly, didn't even know it works with PlayOnLinux

Running CUETools under Wine was discussed briefly [a href='index.php?act=findpost&pid=849452']here[/a] and the followup message [a href='index.php?act=findpost&pid=849933']here[/a]. Both claimed it was working.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Groxxxy on 2014-11-25 12:54:57
All I did was install two components in PoL: dotnet20sp2 and vcrun2008.

So why do I get that message when trying to access files on an external?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-11-25 14:43:01
The prerequisites aren't the problem. There is another [a href='index.php?showtopic=107574']topic[/a] started with a similar issue with an external hard drive.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: grim_lokason on 2014-11-27 20:47:05
Hello,

I have not been able to get the tag i've recently add to musicbrainz with cueripper.
I'm able to see it when i click on the musicbrainz logo at the bottom of cueripper

If i'm not mistaken cueripper get the musicbrainz data from another server and there is an announcement about a change in the DB :
http://blog.musicbrainz.org/2014/11/22/sch...ions-schema-21/ (http://blog.musicbrainz.org/2014/11/22/schema-change-upgrade-instructions-schema-21/)

Could it be possible look at it ?

Regards,
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-11-27 20:52:09
Thanks, i'm working on that.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2014-11-29 10:12:54
Now when FLAC v1.3.1 is out is there any chance we could get it added to CUETools/Ripper
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2014-12-01 01:27:44
any chance of this being addressed? 

i'm sure i've had the tak decoder working before but i can't get it working at all now.  all i'm looking to do is verify files. if i try and modify the path to takc.exe in the options, it doesn't make any difference. also, on a restart, this change is lost and it resets to default. i've also tried putting takc.exe in the cuetools folder and that didn't work either. this is the error:

Quote
Object reference not set to an instance of an object..


using 2.1.5.

edit: 2.1.4 works fine. i can set the path to takc.exe in my encoders folder, job done. i guess i must have used that previously.. 


i re-downloaded 2.1.5 just now to be sure it hasn't been fixed since then.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2014-12-01 20:46:05
Is there any chance that CUETools' "Correct filenames" action could be enhanced to handle image rips that have been split already? Right now it's only possible through a multi-step process:
It would be nice if CUETools could just do this in one swoop, and without having to rely on the eachelper site which is partially broken. Or is there such a feature that I'm just overlooking?

I tried to see if this was a feature of the little-known CUE Corrector (http://cornerstone.ucoz.ru/index/ca_cuesheet_editor/0-31), but its interface is even more cryptic than that of CUETools, so I have yet to figure out if it has a place in my workflow.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-12-01 20:55:55
i re-downloaded 2.1.5 just now to be sure it hasn't been fixed since then.

Actually a fellow user sent a patch and i committed it couple of months ago, so it's just a matter of uploading a new build.

Is there any chance that CUETools' "Correct filenames" action could be enhanced to handle image rips that have been split already?

I'll try.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-12-01 23:45:56
Huh, that's weird. I've been using 2.1.5 all the time and had no problems decoding tak files (my whole library is in tak). Is the bug affecting setting the path on 2.1.5 and I am not affected because I've already set it on 2.1.4?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: d125q on 2014-12-01 23:49:04
Is the bug affecting setting the path on 2.1.5 and I am not affected because I've already set it on 2.1.4?

This. Downloading CUETools 2.1.4, setting takc.exe correctly, and then updating to 2.1.5 worked for me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2014-12-02 00:42:04
thanks for the tips. i managed to get it working on a clean 2.1.5 install by opening settings.txt and replacing this:

Code: [Select]
ExternalDecoders=0


with:

Code: [Select]
ExternalDecoder0Name=takc
ExternalDecoder0Extension=tak
ExternalDecoder0Path=D:\Applications\foobar2000\encoders\takc.exe
ExternalDecoder0Parameters=-d %I -
ExternalDecoders=1


Actually a fellow user sent a patch and i committed it couple of months ago, so it's just a matter of uploading a new build.


that's good news.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2014-12-09 05:30:50
Now when FLAC v1.3.1 is out is there any chance we could get it added to CUETools/Ripper

Experimental build of CUETools 2.1.6 with libFLAC 1.3.1 and has been released: http://www.cuetools.net/wiki/CUETools_Download (http://www.cuetools.net/wiki/CUETools_Download). It also has some bugfixes and a heavily optimised built in flac encoder that produces noticeably smaller files than libFLAC, based on window functions discovered by ktf.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2014-12-09 07:51:34
Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2014-12-09 10:29:53
Now when FLAC v1.3.1 is out is there any chance we could get it added to CUETools/Ripper

Experimental build of CUETools 2.1.6 with libFLAC 1.3.1 and has been released: http://www.cuetools.net/wiki/CUETools_Download (http://www.cuetools.net/wiki/CUETools_Download). It also has some bugfixes and a heavily optimised built in flac encoder that produces noticeably smaller files than libFLAC, based on window functions discovered by ktf.



Thnx a lot Gregory
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-12-09 15:13:38
This is how the new flake compares to flac etc on an AMD Phenom II X4 970 @3.5GHz:

Set 1: a few albums (wav 44.1kHz 16bit): 2:33:09, 1 630 978 738 bytes
Code: [Select]
flac 1.2.1  lv8  0:51 (180x) 809 645 691 (49,64%) [+/- 0MB]
flac 1.3.1  lv8  0:24 (383x) 807 720 851 (49,52%) [- 1,8MB]
flac 1.3.1  lv8e 1:27 (106x) 805 230 363 (49,37%) [- 4,2MB]
flake 2.1.6 lv8  0:51 (180x) 802 127 311 (49,18%) [- 7,2MB]
flake 2.1.6 lv11 1:27 (106x) 796 043 061 (48,80%) [-13,0MB]
tak  2.3.0  p4m  1:28 (104x) 755 009 174 (46,29%) [-52,1MB]

Set 2: hires album (wav 48kHz 24bit): 1:13:58, 1 280 307 724 bytes
Code: [Select]
flac 1.2.1  lv8  1:04 ( 69x) 918 175 228 (71,71%) [+/- 0MB]
flac 1.3.1  lv8  0:26 (171x) 916 311 947 (71,56%) [- 1,8MB]
flac 1.3.1  lv8e 2:02 ( 36x) 915 515 373 (71,50%) [- 2,5MB]
flake 2.1.6 lv8  0:32 (139x) 914 593 071 (71,43%) [- 3,4MB]
flake 2.1.6 lv11 0:58 ( 77x) 910 734 255 (71,13%) [- 7,1MB]
tak  2.3.0  p4m  0:54 ( 82x) 893 934 332 (69,82%) [-23,1MB]


Set 3: hires album (wav 96kHz 24bit): 0:53:48, 1 863 301 258 bytes
Code: [Select]
flac 1.2.1  lv8  1:29 (36x) 1 222 429 935 (65,60%) [+/- 0MB]
flac 1.3.1  lv8  0:33 (98x) 1 216 111 317 (65,26%) [- 6,0MB]
flac 1.3.1  lv8e 2:50 (19x) 1 204 972 348 (64,66%) [-16,6MB]
flake 2.1.6 lv8  0:48 (67x) 1 183 381 592 (63,50%) [-37,2MB]
flake 2.1.6 lv11 1:06 (49x) 1 181 718 745 (63,42%) [-38,8MB]
tak  2.3.0  p4m  1:06 (49x) 1 168 977 920 (62,73%) [-51,0MB]


Not bad, not bad at all.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Anakunda on 2014-12-09 18:34:26
Experimental build of CUETools 2.1.6 with libFLAC 1.3.1 and has been released:


Tried it sortly and I I encounter these annoying two features:
-CUE converter sometimes doesn't transfer ISRC codes from old to new CUE (specially when converting Image->Tracks
  Image->Image seems OK
-CUE converter does log undesired conversion from Unicode to ANSI (can't be checkloged anymore)
can be fixed in next build plz
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2014-12-10 16:48:59
Been thinking a little here  ...... what about making CUETools look/scan for the 3rd Party Encoders that it can use in it's 'installation' folder, ie. in the root folder or in a subfolder called say 'encoders' or something like that.

Think this would be a great function to have added
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mountainman3520 on 2014-12-17 21:36:54
Hello,

I have a few hundred CDs I want to transfer onto my various digital music players and I'm perfecting my ripping process.

For long term archival, I'm creating a single uncompressed wav+cue files using EAC.  I tried cueripper but it did not work correctly in secure mode with my drive (LG GBW-H20L).  It continuously reread every block many times taking forever and eventually overheating the drive causing it to shutdown and terminate the rip.  So I could only use burst mode with cueripper.  EAC works perfectly with this same drive and on the same disks using secure mode so unless there's a fix I'll have to stick with EAC.

I then use cuetools to split the wav and compress each song into m4a lossy AAC using the nero plugin.

This is mostly working but I have a few questions/comments:
(1) cueripper has a nice function for searching online to find album art, and then allowing user to click through the options to the right one.  But I can't use cueripper per above issue.  cuetools doesn't seem to have a working function to find album art so I've been manually finding it and placing a folder.jpg file in the input directory, which cuetools automatically finds and then properly embeds into each m4a file.  This works but its manual.  Is there a way to find and select album art directly in cuetools or is that feature only in cueripper?  If so, I suggest a feature enhancement to include the same album art search and select feature in cuetools.

(2)  Per my above process, cuetools is creating the artist and album directories and song files, hence assigning the names to these.  But its making annoying character substitutions and I can't seem to find any option setting to stop it from doing so.  It sometimes replaces legal filename characters such as ' ! and ? with _.  The weird thing is that is doesn't do this 100% of the time.  I don't understand the pattern for when it does or does not substitute characters.  Can anyone explain?  Any way to turn this off or control it or is there a good reason for why its doing this and I should learn to love it?

Thank you!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-12-18 00:02:17
I can't help with the drive but I'll try with the 2 points.

(1) As you already figured out, the 'Album art search' is not yet functioning in CUETools. However since you are currently using EAC to rip WAV+CUE why don't you select your cover art at that time? Using the CTDB EAC Plugin (http://www.cuetools.net/wiki/CTDB_EAC_Plugin) would get you to the same cover art as CUERipper. You could also use the freedb Metadata Plugin (if it was installed) to find covers. The cover art is saved with the same filename as the CUE and WAV so in CUETools you could add the string %filename%.jpg to the Local cover art search (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#Cover_Art) so CUETools can find it. This only works with .jpg files and may not work in batch modes due to a popup window.

(2) First off ? is not a legal filename character. You can't use  / \ : * ? " < > | in Windows folder or file names. Because the substitutions do not happen all the time, the changes may be imported with the Metadata and CUETools may be just reading the characters as they are. However, the setting in CUETools that would handle this is the Remove special characters except: (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools#Audio_Filenames) found under Force ANSI filenames (if both are checked).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mountainman3520 on 2014-12-18 05:36:30
I can't help with the drive but I'll try with the 2 points.

(1) As you already figured out, the 'Album art search' is not yet functioning in CUETools. However since you are currently using EAC to rip WAV+CUE why don't you select your cover art at that time? Using the CTDB EAC Plugin (http://www.cuetools.net/wiki/CTDB_EAC_Plugin) would get you to the same cover art as CUERipper. You could also use the freedb Metadata Plugin (if it was installed) to find covers. The cover art is saved with the same filename as the CUE and WAV so in CUETools you could add the string %filename%.jpg to the Local cover art search (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#Cover_Art) so CUETools can find it. This only works with .jpg files and may not work in batch modes due to a popup window.

(2) First off ? is not a legal filename character. You can't use  / \ : * ? " < > | in Windows folder or file names. Because the substitutions do not happen all the time, the changes may be imported with the Metadata and CUETools may be just reading the characters as they are. However, the setting in CUETools that would handle this is the Remove special characters except: (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools#Audio_Filenames) found under Force ANSI filenames (if both are checked).


Thank you!  Very helpful!

(1)  I've previously tried to get the album art feature of EAC working and failed but your comments encouraged me to try again and I found the problem.  I had both the freedb and ctdb plugins installed, but I didn't notice the button to swap metadata lookup engines and had not tried the freedb mode.  I was using the CTDB plugin but the default install of the latest EAC included v2.1.3, which didn't include the album art lookup feature.  I copied the latest CTDB plugin v2.1.5 into the EAC directory and now album art is working for CTDB metadata lookups.  I tried the freedb artwork lookup engine and it also works.  GREAT!

I also used the method you described to setup CUETools 2.1.5 to find the album art file from EAC.  Works great!  I see what you mean about it breaking batch mode with the popup window.  Probably would be a good change if they skipped the popup window when only one file is found and just selected it automatically.  As it is I have to accept the one file even though there are no other options, and therefore can't use batch mode.

(2)  Okay, I'll just get used to having the filenames contain _ substitution characters.  The proper names do propagate all the way through in CUE files and tags and most of my players are smart enough to display the tag info instead of filename these days.

You helped me improve my automation.  Thank you.  I'll still think of you as I rip the 500th CD!


Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: KenO on 2014-12-23 17:35:21
Am new to CUERipper and would like to use it to encode Opus.

Checking the forum found post by aarcane Oct 13 2014, 02:54 "I've discovered another small bug using the opus codec.  The opus codec goes into a file with .opus as the extension, but the container is simply a standard ogg container.  Therefore, taglib/ogg should be used to add tags, however, taglib is attempting to use taglib/opus, which is not defined.  Other than the present inability to tag .opus files, the opus container seems to work simply by pointing the encoder at opustools.  This is occuring as of cuetools 2.1.5.  Opus tools is available from here:  http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) and I used the following settings to configure opus encoding..."

Has CUETools 2.1.6 eliminated these Opus bugs?

Thanks

Ken

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: KenO on 2014-12-23 17:41:17
Recently heard about Opus Audio Format and was impressed with the audio quality.

Would like to run some audio tests using my own CDs.

Did some searching concerning Windows CD Rippers with ability to encode Opus and decided to use CUERipper.  Checked the CUERipper Settings page and was overwhelmed by the options.

Appreciate any suggestions concerning what has worked best for all types of music.

Thanks

Ken
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2014-12-24 21:16:15
(2) First off ? is not a legal filename character. You can't use  / \ : * ? " < > | in Windows folder or file names. Because the substitutions do not happen all the time, the changes may be imported with the Metadata and CUETools may be just reading the characters as they are. However, the setting in CUETools that would handle this is the Remove special characters except: (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_CUETools#Audio_Filenames) found under Force ANSI filenames (if both are checked).

There is another way to handle those illegal characters - using the full width alternatives (? vs ?). This makes filenames partially unicode, but most players should be able to handle them nowadays.
Sadly, CUETools doesn't seem to support foobar2000's $replace() function (hint hint), so I'm leaving the "force ANSI names" options checked and then running a "File operations -> rename to" action in foobar2000, with the renaming pattern looking like this:
Code: [Select]
$replace($ifgreater(%totaldiscs%,1,%discnumber%.,)%tracknumber%. [%artist% - ]%title%,':','?','*','?','?','?','"','”','<','?','>','?','|','?')

This handles all illegal characters except the / \ characters. There is actually a full width /, namely ?, but foobar2000 won't let / be replaced by anything, so those have to be renamed by hand.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zarggg on 2014-12-25 01:52:45
That would work, yes, but might be confusing for novice users who aren't aware of the existence of full-width alternatives.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: aarcane on 2014-12-25 06:19:33
Am new to CUERipper and would like to use it to encode Opus.

Checking the forum found post by aarcane Oct 13 2014, 02:54 "I've discovered another small bug using the opus codec.  The opus codec goes into a file with .opus as the extension, but the container is simply a standard ogg container.  Therefore, taglib/ogg should be used to add tags, however, taglib is attempting to use taglib/opus, which is not defined.  Other than the present inability to tag .opus files, the opus container seems to work simply by pointing the encoder at opustools.  This is occuring as of cuetools 2.1.5.  Opus tools is available from here:  http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) and I used the following settings to configure opus encoding..."

Has CUETools 2.1.6 eliminated these Opus bugs?

Thanks

Ken


I can confirm by testing that the Opus bug is NOT yet fixed.  I'm hopeful for 2.1.7, but I won't hold my breath as the dev hasn't even acknowledged the bug yet.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-12-25 13:22:42
I'm not the developer. Though support for opus was added to the ogg section of taglib it has not been added (so far) to taglib-sharp (taglib#). CUETools uses taglib-sharp to add tags. Someone did request (https://bugzilla.gnome.org/show_bug.cgi?id=686976) opus support in taglib-sharp back in 2012.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pixymisa on 2014-12-28 23:28:10
With cuetools 2.1.5, I am seeing inconsistent results in the cue file produced when encoding tracks from a single wav and cue image.  The result will have some FILE statements misplaced and INDEX 00 statements added.  Here is an actual cue files produced where the inconsistency appears twice, once for TRACK 02 and once for TRACK 03.  Is there a way to prevent this from happening or do I need to manually correct all cue files produced by cuetools?

Code: [Select]
PERFORMER "Sherman Chung"
TITLE "Thunder Party"
REM GENRE "Pop"
REM DATE 2008
REM RELEASEDATE 2008.11.26
REM DISCID 8E08A90A
FILE "01. 80 Commandments.flac" WAVE
  TRACK 01 AUDIO
    TITLE "80 Commandments"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Tiny Tablets"
    PERFORMER "Sherman Chung"
    INDEX 00 03:42:41
FILE "02. Tiny Tablets.flac" WAVE
    INDEX 01 00:00:00
  TRACK 03 AUDIO
    TITLE "Red Brick"
    PERFORMER "Sherman Chung"
    INDEX 00 03:41:59
FILE "03. Red Brick.flac" WAVE
    INDEX 01 00:00:00
FILE "04. Wild Lily.flac" WAVE
  TRACK 04 AUDIO
    TITLE "Wild Lily"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
FILE "05. Beat Time.flac" WAVE
  TRACK 05 AUDIO
    TITLE "Beat Time"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
FILE "06. Shut Up.flac" WAVE
  TRACK 06 AUDIO
    TITLE "Shut Up"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
FILE "07. Able To Buy.flac" WAVE
  TRACK 07 AUDIO
    TITLE "Able To Buy"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
FILE "08. Eyes Don't Lie.flac" WAVE
  TRACK 08 AUDIO
    TITLE "Eyes Don't Lie"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
FILE "09. One Heart Two Use.flac" WAVE
  TRACK 09 AUDIO
    TITLE "One Heart Two Use"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
FILE "10. Memories Of a Break-up.flac" WAVE
  TRACK 10 AUDIO
    TITLE "Memories Of a Break-up"
    PERFORMER "Sherman Chung"
    INDEX 01 00:00:00
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2014-12-28 23:56:56
Right now with current stable version and in 2.1.6 cant choice any Platform...

(https://pp.vk.me/c622027/v622027717/11feb/oWImroLrWDQ.jpg)
(https://pp.vk.me/c622027/v622027717/11ff2/seA9tMH7U7o.jpg)

My videocard still nVidia GeForce GTS 250, drivers: 340.52
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2014-12-29 00:31:07
Does anyone know how to force CUETools to add a leading zero to single digit numbers in the tags upon conversion? For example, I would like the tags of the converted files to be consistent with those produced by EAC, having 01, 02, 03, etc. in the "Track Number" field, as opposed to 1, 2, 3 etc. that CUETools outputs. It seems as if it would be a simple task, yet this one continues to stump me.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-12-29 00:45:07
With cuetools 2.1.5, I am seeing inconsistent results in the cue file produced when encoding tracks from a single wav and cue image.  The result will have some FILE statements misplaced and INDEX 00 statements added.  Here is an actual cue files produced where the inconsistency appears twice, once for TRACK 02 and once for TRACK 03.  Is there a way to prevent this from happening or do I need to manually correct all cue files produced by cuetools?

That is a Multiple files with gaps (Noncompliant) (http://wiki.hydrogenaud.io/index.php?title=Cuesheet#Multiple_files_with_gaps_.28Noncompliant.29) CUE. Users often prefer this type of CUE as it retains the gap information from the original Image + CUE for burning to CD. As far as I know there is no way to disable this action in CUETools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: anaono on 2014-12-29 17:03:05
I have the error in CueTools, if i verify AR:

AR: database access error: Der Remotename konnte nicht aufgelöst werden: 'www.accuraterip.com', CTDB: database access error: Der Remotename konnte nicht aufgelöst werden: 'db.cuetools.net'.


nslookup www.accuraterip.com
gives the output:

Server:  fritz.box
Address:  xxx.xxx.xxx.1

Nicht autorisierende Antwort:
Name:    accuraterip.com
Address:  89.238.133.247
Aliases:  www.accuraterip.com



ping www.accuraterip.com
gives the output:

Ping wird ausgeführt für accuraterip.com [89.238.133.247] mit 32 Bytes Daten:
Antwort von 89.238.133.247: Bytes=32 Zeit=51ms TTL=115
Antwort von 89.238.133.247: Bytes=32 Zeit=48ms TTL=115
Antwort von 89.238.133.247: Bytes=32 Zeit=49ms TTL=115
Antwort von 89.238.133.247: Bytes=32 Zeit=49ms TTL=115

Ping-Statistik für 89.238.133.247:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 48ms, Maximum = 51ms, Mittelwert = 49ms
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: arpeggio on 2014-12-29 21:12:33
Does anyone know how to force CUETools to add a leading zero to single digit numbers in the tags upon conversion? For example, I would like the tags of the converted files to be consistent with those produced by EAC, having 01, 02, 03, etc. in the "Track Number" field, as opposed to 1, 2, 3 etc. that CUETools outputs. It seems as if it would be a simple task, yet this one continues to stump me.

+1
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: pixymisa on 2014-12-31 17:22:03
Does anyone know how to force CUETools to add a leading zero to single digit numbers in the tags upon conversion? For example, I would like the tags of the converted files to be consistent with those produced by EAC, having 01, 02, 03, etc. in the "Track Number" field, as opposed to 1, 2, 3 etc. that CUETools outputs. It seems as if it would be a simple task, yet this one continues to stump me.


According to documentation on templates (http://www.cuetools.net/wiki/Cuetools_templates), you should be able to do it by using the function $ifgreater(x,y,a,b).


With cuetools 2.1.5, I am seeing inconsistent results in the cue file produced when encoding tracks from a single wav and cue image.  The result will have some FILE statements misplaced and INDEX 00 statements added.  Here is an actual cue files produced where the inconsistency appears twice, once for TRACK 02 and once for TRACK 03.  Is there a way to prevent this from happening or do I need to manually correct all cue files produced by cuetools?

That is a Multiple files with gaps (Noncompliant) (http://wiki.hydrogenaud.io/index.php?title=Cuesheet#Multiple_files_with_gaps_.28Noncompliant.29) CUE. Users often prefer this type of CUE as it retains the gap information from the original Image + CUE for burning to CD. As far as I know there is no way to disable this action in CUETools.


OK.  Thank you.  Maybe one can hope for a "Force Compliant" option in the future.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lvqcl on 2014-12-31 17:31:53
OK.  Thank you.  Maybe one can hope for a "Force Compliant" option in the future.

What's the point of this?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2014-12-31 18:33:59
According to documentation on templates (http://www.cuetools.net/wiki/Cuetools_templates), you should be able to do it by using the function $ifgreater(x,y,a,b).

That document is about output path templates for folder and file names. It won't help with tagging.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2015-01-01 01:55:23
According to documentation on templates (http://www.cuetools.net/wiki/Cuetools_templates), you should be able to do it by using the function $ifgreater(x,y,a,b).

That document is about output path templates for folder and file names. It won't help with tagging.


That is precisely the problem. Templates for tagging do not exist in CUETools, which is unfortunate.

My current solution is to use MP3tag for this task. I created a new Action, using format string [$num(%track%,2)] for the "TRACK" field. That will instantly change all single digit track numbers in the tags into a leading zero format. Very simple and very effective. However, I wish I didn't have to go through this extra step of loading all of my converted files into MP3tag to do this. It would be nice if this could be done within CUETools. All it would require would be to provide the user with an advanced option of choosing either %track number% (single digit) or %tracknumber% (two digits).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: anaono on 2015-01-01 11:15:03
my CUETools doesn't run anymore
Can anyone help me?

I can access to www.accuraterip.com and to db.cuetools.net via browser and via nslookup and via ping, but CUETools yields "the remote name could not be resolved"

I have the error in CueTools, if i verify AR:

AR: database access error: Der Remotename konnte nicht aufgelöst werden: 'www.accuraterip.com', CTDB: database access error: Der Remotename konnte nicht aufgelöst werden: 'db.cuetools.net'.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-01-01 13:34:07
New firewall/Internet security software?
Proxy (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#Proxy) settings correct for how your machine connects to the Internet?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: anaono on 2015-01-01 18:58:12
> New firewall/Internet security software?
No, i have tested to put off:
- WIN-Firewall and
- Avira Antivir
==> no effect.

My OS ist WIN 7.

> Proxy settings ?
I don't have changed anything about Proxy settings, but i will read and test it now. And after that i will give feedback ...

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: anaono on 2015-01-01 20:25:44
Proxy settings:
the default was: system; 127.0.0.1; 8080
I have tested: none
and: custom with 127.0.0.1; 8080
==> no effect, error still remains
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: anaono on 2015-01-02 10:47:56
I have found the commandline tool ArCueDotNet.exe in the installation folder of CueTools and it works   
No error "the remote name could not be resolved" occurs anymore.

Now i need the four options:

-w
writes AccurateRip-Tags

-i
ignores existing AccurateRip-Tags (works like i have deleted the AccurateRip-Tags before calling ArCueDotNet)

the combination: -w -i or: -i -w
ignores and overwrites existing AccurateRip-Tags

e.g.: -o65
uses the offset 65 (and calculates V2 for this offset)

o without offset declaration: -o
calculates the V2 value for all detected offsets (like running ArCueDotNet multiple times with -o<offset1>,  -o<offset2>, ...). This is usefull to see the best offset for a Rip without "Read offset correction".

The Pregap is used from the cuesheet e.g.: "PREGAP 00:00:32" or from the m3u-playlist from the first comment line e.g.:
"# PREGAP 00:00:32"

e.g.: -p00:00:33
overwrites the Pregap from the cuesheet and the m3u-playlist respectively.

Perhaps the following is usefull also:
e.g.: -p00:00:00-00:00:32
or short: -p-00:00:32
tests all Pregaps: from no Pregap, PREGAP 00:00:01, PREGAP 00:00:02, ... to PREGAP 00:00:32, if the Rip is existing in the AccurateRip DB


-v --verbose
verbose mode, exists already


Please write three of the AccurateRip-Tags at Bottom of the -verbose output, e.g.:
<ACCURATERIPCOUNT> : 9
<ACCURATERIPCOUNTALLOFFSETS> : 17; 16
<ACCURATERIPTOTAL> : 27; 26


Where can i post this request for the developers?
Are there more users found these options for ArCueDotNet.exe usefull?
I hope this makes CUETools even more useful.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2015-01-24 19:13:39
I've was using Cuetools 2.1.4 for a long while so I decided to look if there was an update. I found 2.1.5 and tried it.
To my surprise I couldn't find the scripts tab to add my custom script. I went to this forum and I read that a dll was removed because of a false positive virus alert.
I think it's a bit radical to remove a feature instead of reporting the dll to the maker of the virus scanner as a false positive.

Well, I thought, let's run the new version next to the old one, so I can revert to the old one if I need my script.
But because they use the same directory for the settings I have to rename the 2 settings.txt every time.

Is it possible to introduce the scripts back in version 2.1.6? Or make it an optional plugin so we can choose if we want to use it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2015-01-24 19:48:45
You can keep settings separate by removing user_profiles_enabled file. Settings will be written to the CUETools folder.

THe scripts could have been nice, but very few people could actually use them.
I was hoping that this handful of people would find it not much more difficult to just build their own custom version of CUETools.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 2015-01-24 20:43:12
Thanks for the user_profiles_enabled tip.
Is there a tutorial to build your own custom version? I'm not a programmer, so I don't have a clue yet of what is needed to do that.

P.S. I also have Avast, I never had the virus alert. Just scanned the 2.1.4 directory which came out OK.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: CrusherW9 on 2015-01-29 06:56:39
I was hoping that this handful of people would find it not much more difficult to just build their own custom version of CUETools.

I'm not the most versed with .Net, I only have some experience with an MVC webapp. But I do have some experience with other languages. I took a look at the code for CUETools and found it to be a bit daunting. Admittedly, I'm not the best programmer ever as I'm only about half way into my Computer Science degree. That said, I'd love to maybe take a crack at further enhancing it. I'm going to continue looking through the code, but if you could maybe give me some sort of overview of how everything is structured, that would help me tremendously.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-02-09 04:46:42
Minor bug report: CUERipper puts two "FLAGS PRE" lines in the cue sheet when it encounters pre-emphasis flags. I don't know if it matters, but the flags were only in the subcode, not the TOC.
Code: [Select]
REM ACCURATERIPID 00157f63-00b7f7e8-a10bac0b
REM DISCID A10BAC0B
PERFORMER "Howard Jones"
TITLE "Human's Lib"
CATALOG 0075596034623
REM DATE 1984
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.6 Copyright © 2008-13 Grigory Chudov"
FILE "[00] Howard Jones - (HTOA).flac" WAVE
  TRACK 01 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Conditioning"
INDEX 00 00:00:00
FILE "[01] Howard Jones - Conditioning.flac" WAVE
INDEX 01 00:00:00
  TRACK 02 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "What is Love? (Extended Version)"
INDEX 00 04:33:03
FILE "[02] Howard Jones - What is Love_ (Extended Version).flac" WAVE
INDEX 01 00:00:00
FILE "[03] Howard Jones - Pearl in the Shell.flac" WAVE
  TRACK 03 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Pearl in the Shell"
INDEX 01 00:00:00
FILE "[04] Howard Jones - Hide and Seek.flac" WAVE
  TRACK 04 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Hide and Seek"
INDEX 01 00:00:00
FILE "[05] Howard Jones - Hunt the Self.flac" WAVE
  TRACK 05 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Hunt the Self"
INDEX 01 00:00:00
  TRACK 06 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "New Song"
INDEX 00 03:42:12
FILE "[06] Howard Jones - New Song.flac" WAVE
INDEX 01 00:00:00
  TRACK 07 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Don't Always Look at the Rain"
INDEX 00 04:15:25
FILE "[07] Howard Jones - Don't Always Look at the Rain.flac" WAVE
INDEX 01 00:00:00
FILE "[08] Howard Jones - Equality.flac" WAVE
  TRACK 08 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Equality"
INDEX 01 00:00:00
  TRACK 09 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Natural"
INDEX 00 04:27:07
FILE "[09] Howard Jones - Natural.flac" WAVE
INDEX 01 00:00:00
  TRACK 10 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "Human's Lib"
INDEX 00 04:26:53
FILE "[10] Howard Jones - Human's Lib.flac" WAVE
INDEX 01 00:00:00
  TRACK 11 AUDIO
FLAGS PRE
FLAGS PRE
PERFORMER "Howard Jones"
TITLE "China Dance"
INDEX 00 04:04:00
FILE "[11] Howard Jones - China Dance.flac" WAVE
INDEX 01 00:00:00
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: edwardar on 2015-02-09 19:39:00
Minor bug report: CUERipper puts two "FLAGS PRE" lines in the cue sheet when it encounters pre-emphasis flags. I don't know if it matters, but the flags were only in the subcode, not the TOC.


I'd call that a useful design feature rather than a bug.

How else would you know whether a rip has pre-emphasis?  By manually checking the log?
And if you wanted to burn your rip to a CD-R, you'd need to set this flag (unless there is a way of burning the flag in the subcode?).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-02-11 06:52:27
I said it puts two FLAGS PRE lines on each track. It's supposed to only write one per track.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-02-11 12:11:10
Someone did report a [a href='index.php?showtopic=107463']similar problem[/a].
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2015-02-12 06:20:08
Right now with current stable version and in 2.1.6 cant choice any Platform...

(https://pp.vk.me/c622027/v622027717/11feb/oWImroLrWDQ.jpg)
(https://pp.vk.me/c622027/v622027717/11ff2/seA9tMH7U7o.jpg)

My videocard still nVidia GeForce GTS 250, drivers: 340.52

anything new about fixing this problem?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: edwardar on 2015-02-12 20:30:28
I said it puts two FLAGS PRE lines on each track. It's supposed to only write one per track.

Not my finest hour - many apologies 
I have several pre-emphasis CDs, but ripped them a while back with 2.1.4, which may be why I haven't come across the bug yet.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2015-02-22 10:44:16
Has it already been reported that FlacCL is showing a negative filesize when the encoded file is bigger than 2^31 bytes?

Code: [Select]
>CUETools.FLACCL.cmd.exe --verify file.wav
CUETools FLACCL 2.1.6, Copyright (C) 2010-2013 Grigory Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : file.wav
File Info : 48000kHz; 6 channel; 16 bit; 02:05:22.2720000
Device    : GeForce GT 640, Platform: "NVIDIA CUDA", Version: OpenCL 1.1 CUDA 7.
0.23, Driver: 347.52
Results   : 74,15x; -2107532821 bytes in 00:01:41.4469782 seconds;

Size of encoded file: 2187434475 bytes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2015-02-23 14:49:36
And this happens when the file is bigger than 4GB:
Code: [Select]
>CUETools.FLACCL.cmd.exe -5 --verify test.wav
CUETools FLACCL 2.1.6, Copyright (C) 2010-2013 Grigory Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename  : test.wav
File Info : 48000kHz; 6 channel; 16 bit; 04:08:33.0810000
Device    : GeForce GT 640, Platform: "NVIDIA CUDA", Version: OpenCL 1.1 CUDA 7.
0.23, Driver: 347.52
Results   : 58,62x; 140368563 bytes in 00:04:14.4052468 seconds;

Actual filesize is 4435335859 bytes (2^32+140368563 bytes).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: audiophool on 2015-02-23 15:57:01
^^^ Could be a case of "garbage in, garbage out." A WAV greater than 4 GB is non-compliant.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Zarggg on 2015-02-24 16:12:42
I'll concede the "non-compliant" point, but it might still be a good idea to future-proof the software if there does come a day when >4GB source PCM files are common.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Elbart on 2015-02-24 17:11:14
^^^ Could be a case of "garbage in, garbage out." A WAV greater than 4 GB is non-compliant.

It is? Didn't know that.
That would explain the error ("partial sample") I got when encoding the 4.0x GB big file with flac.exe. 
FlacCL was encoding it fine, though.

Thanks for your reply.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lvqcl on 2015-02-24 17:21:20
That would explain the error ("partial sample") I got when encoding the 4.0x GB big file with flac.exe. 

flac has --ignore-chunk-sizes option for such files:
Quote
WAV and AIFF files both have an unsigned 32 bit numbers in the file header which specifes the length of audio data. Since this number is unsigned 32 bits, that limits the size of a valid file to being just over 4 Gigabytes. Files larger than this are mal-formed, but should be read correctly using this option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-02-28 03:29:42
What about CUERipper? Is the latest version reliable, compared to EAC, for example? I tried to rip a CD and I noticed that, if a certain option is selected, it produces a log almost identical to the EAC one. I suppose that EAC and CUERipper share the same error detection/handling techniques/files? Anyway, I would suggest to add more editable fields, here is a screenshot of EAC:

(http://i.snag.gy/OBUz0.jpg)

I would suggest to add the fields marked in red, because they seem to be missing from CUERipper, whilst being useful.
Another cool thing to do, could be to add GD3 metadata retrieval. But I don't know if it's free.
These are only suggestions, what do you think? Thanks for your hard work!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-02-28 03:46:56
I have found the commandline tool ArCueDotNet.exe in the installation folder of CueTools and it works   

e.g.: -o65
uses the offset 65 (and calculates V2 for this offset)

o without offset declaration: -o
calculates the V2 value for all detected offsets (like running ArCueDotNet multiple times with -o<offset1>,  -o<offset2>, ...). This is usefull to see the best offset for a Rip without "Read offset correction".


I would find that to be useful for some of my albums. Moreover, would there be a way to add --verbose to "CUETools.exe /verify" mode? Here is the output of ArCueDotNet.exe with -v option:

Code: [Select]
[CUETools log; Date: 28/02/2015 04:42:21; Version: 2.1.5]
[CTDB TOCID: LAKiIVhc1gSqZ8BE.7VGBxXwMaE-] found.
        [ CTDBID ] Status
        [5c7170fc] (19/21) Accurately ripped
        [bb2246f5] (01/21) No match
        [5db9fe31] (01/21) No match
Track | CTDB Status
  1   | (19/21) Accurately ripped
  2   | (20/21) Accurately ripped
  3   | (20/21) Accurately ripped
  4   | (20/21) Accurately ripped
  5   | (20/21) Accurately ripped
  6   | (20/21) Accurately ripped
  7   | (20/21) Accurately ripped
  8   | (20/21) Accurately ripped
  9   | (20/21) Accurately ripped
10   | (20/21) Accurately ripped
11   | (20/21) Accurately ripped
12   | (20/21) Accurately ripped
[AccurateRip ID: 0019e705-00f3b536-9e0e480c] found.
Track   [  CRC   |   V2   ] Status
01     [54d5b239|8c859a29] (07+12/22) Accurately ripped
02     [9abaa277|446f813f] (07+13/23) Accurately ripped
03     [e671a3ee|df8aefac] (07+12/22) Accurately ripped
04     [131645c5|08404059] (07+13/23) Accurately ripped
05     [fa677611|1fcf6226] (07+12/21) Accurately ripped
06     [a48fb312|abf5ba0c] (07+13/22) Accurately ripped
07     [482b2273|1371a315] (07+12/22) Accurately ripped
08     [061ecc0d|40eb99d7] (07+12/22) Accurately ripped
09     [a9a43e39|455299f8] (07+12/22) Accurately ripped
10     [c5d77042|4c99c432] (07+12/22) Accurately ripped
11     [5e115af1|060f38c5] (07+12/21) Accurately ripped
12     [9504d38d|fd07e8a8] (07+13/22) Accurately ripped
Offsetted by -664:
01     [cb3b9709] (03/22) Accurately ripped
02     [9df3c3be] (03/23) Accurately ripped
03     [19dbfde0] (03/22) Accurately ripped
04     [217183dd] (03/23) Accurately ripped
05     [34245dad] (02/21) Accurately ripped
06     [7ead2d66] (02/22) Accurately ripped
07     [e3a0ad42] (03/22) Accurately ripped
08     [38bcafa1] (03/22) Accurately ripped
09     [2c2d1bae] (03/22) Accurately ripped
10     [ffd9b6c1] (03/22) Accurately ripped
11     [3b71ecd8] (02/21) Accurately ripped
12     [efd1a32c] (02/22) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   99,9 [EF433381] [26CF379B]
01   98,9 [C27A1E39] [CEEB2201]   CRC32
02   93,4 [AB077A50] [FED0030F]   CRC32
03   93,4 [3A917A0E] [FD08F022]   CRC32
04   99,9 [9126A647] [9DD38039]   CRC32
05   99,9 [7CF0263A] [37888463]   CRC32
06   99,9 [9DFFF022] [BA5F9850]   CRC32
07   99,9 [DA170E31] [6C559762]   CRC32
08   99,9 [EA488401] [68C255C0]   CRC32
09   99,9 [846B12B2] [93950B27]   CRC32
10   89,1 [9B55BB04] [309042ED]   CRC32
11   99,9 [CBBEA6BA] [34C34B04]   CRC32
12   99,9 [B8A9843C] [D100069D]   CRC32


Here is the output of CUETools.exe with /verify option:

Code: [Select]
[CUETools log; Date: 28/02/2015 04:44:29; Version: 2.1.5]
[AccurateRip ID: 0019e705-00f3b536-9e0e480c] found.
Track   [  CRC   |   V2   ] Status
01     [54d5b239|8c859a29] (07+12/22) Accurately ripped
02     [9abaa277|446f813f] (07+13/23) Accurately ripped
03     [e671a3ee|df8aefac] (07+12/22) Accurately ripped
04     [131645c5|08404059] (07+13/23) Accurately ripped
05     [fa677611|1fcf6226] (07+12/21) Accurately ripped
06     [a48fb312|abf5ba0c] (07+13/22) Accurately ripped
07     [482b2273|1371a315] (07+12/22) Accurately ripped
08     [061ecc0d|40eb99d7] (07+12/22) Accurately ripped
09     [a9a43e39|455299f8] (07+12/22) Accurately ripped
10     [c5d77042|4c99c432] (07+12/22) Accurately ripped
11     [5e115af1|060f38c5] (07+12/21) Accurately ripped
12     [9504d38d|fd07e8a8] (07+13/22) Accurately ripped
Offsetted by -664:
01     [cb3b9709] (03/22) Accurately ripped
02     [9df3c3be] (03/23) Accurately ripped
03     [19dbfde0] (03/22) Accurately ripped
04     [217183dd] (03/23) Accurately ripped
05     [34245dad] (02/21) Accurately ripped
06     [7ead2d66] (02/22) Accurately ripped
07     [e3a0ad42] (03/22) Accurately ripped
08     [38bcafa1] (03/22) Accurately ripped
09     [2c2d1bae] (03/22) Accurately ripped
10     [ffd9b6c1] (03/22) Accurately ripped
11     [3b71ecd8] (02/21) Accurately ripped
12     [efd1a32c] (02/22) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   99,9 [EF433381] [26CF379B]          
01   98,9 [C27A1E39] [CEEB2201]   CRC32  
02   93,4 [AB077A50] [FED0030F]   CRC32  
03   93,4 [3A917A0E] [FD08F022]   CRC32  
04   99,9 [9126A647] [9DD38039]   CRC32  
05   99,9 [7CF0263A] [37888463]   CRC32  
06   99,9 [9DFFF022] [BA5F9850]   CRC32  
07   99,9 [DA170E31] [6C559762]   CRC32  
08   99,9 [EA488401] [68C255C0]   CRC32  
09   99,9 [846B12B2] [93950B27]   CRC32  
10   89,1 [9B55BB04] [309042ED]   CRC32  
11   99,9 [CBBEA6BA] [34C34B04]   CRC32  
12   99,9 [B8A9843C] [D100069D]   CRC32  
----------------------------------------------------------


As you can see, this second mode misses many good CTDB infos. Anyway, it would be cool for stats to include an option to add the [ CRC32  ] [W/O NULL]  columns for each different pressing (calculated at different offsets). It could take longer to elaborate, but one could choose to deactivate the option.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-02-28 06:50:02
What about CUERipper? Is the latest version reliable, compared to EAC, for example?

Define reliable.  CUERipper is like EAC and other "secure" rippers in that it has a strategy for detecting possible read errors (via re-reads and/or C2 pointers), and re-reading in a cache-defeating manner, all in an attempt to produce consistent data. It is also like those other rippers in that it checks the AccurateRip and CUETools databases to see if your rip is a match for others in the database, even if you do an ordinary "burst" rip rather than use the secure/paranoid modes. So, I think the answer to your question is yes.

IMHO, the most reliable possible-error detection is the AccurateRip and CTDB checking, at least for commercial CDs that other people have ripped and submitted to those databases. Re-reading or using C2 pointers to catch possible errors is good, too, but ideally you want to work the drive as little as possible. For commercial CDs, you only need the burst mode of EAC or most other rippers, plus verification in AccurateRip/CTDB. But if you rip a lot of damaged/defective discs, or you don't care about wear & tear of the drive, or your drive just doesn't perform very well in burst mode, then the convenience features of CUERipper or dbPowerAmp start looking more appealing. Personally I do a lot of whole-disc rips and my drive is not the greatest, so I just use CUERipper's secure mode for every rip, and I'm very happy with its simplicity and the price is right (free).

Quote
I tried to rip a CD and I noticed that, if a certain option is selected, it produces a log almost identical to the EAC one. I suppose that EAC and CUERipper share the same error detection/handling techniques/files?

Pretty much. They are not exactly the same; every ripper has a different idea of how to go about it, and the level of control the user has over each part of the process.

One thing to beware of is that CUERipper's EAC-style log will say "Copy OK" on all tracks, even if there were suspicious sectors. This is a superficial problem in the log; it doesn't mean CUERipper missed errors. I don't recall why it happens, but a search of this forum will probably reveal the answer.

Quote
I would suggest to add the fields marked in red, because they seem to be missing from CUERipper, whilst being useful.

I'll just comment on the Gap column. Like EAC, CUERipper scans for gaps and other indexes when generating a cue sheet, which is where that info lives. Unlike in EAC, in CUERipper you don't have the option of doing this scan ahead of time to see the info in a Gap column, and you can't choose any options to control how the detection is done. In my experience, you don't need any of that in CUERipper; it just works.

Pre-scanning for gaps in EAC is only something to do for odd situations where:
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-02-28 14:01:16
(There may be other reasons to pre-scan for gaps in EAC, but they are for even more obscure situations, like helping you decide whether you want to rip a TAO-mode CD-R with gaps removed, or do an index-based rip of a CD which uses gaps as non-silent interludes.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-02-28 17:23:50
Thanks for your detailed answer, anyway I still haven't understood which kind of errors CUETools is able to report. For example, I see that the following is reported:

Suspicious position X:XX:XX

What about this?:

Missing samples

Moreover, how does Test&Copy really works? Someone tried to rip a scratched CD with CUERipper and, whilst reporting suspicious positions, the Test CRC was the same of Copy CRC. How could be that possible? I thought that Test & Copy, meant read 1st time, calculate CRC, read 2nd time for copy, calculate CRC, shouldn't it be like that?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-02-28 17:58:45
See [a href='index.php?act=findpost&pid=793333']Post #1851[/a]
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-02-28 19:04:55
See [a href='index.php?act=findpost&pid=793333']Post #1851[/a]


Excellent explaination, so with CUERipper I suppose the way to go for the highest chance of accurate rip would be Paranoid mode with no Test&Copy. One last suggestion, I just tried to rip with that setting, but the log seems to be identical to the one produced by a Secure mode with no Test&Copy. So, there is absolutely no way to distinguish between the two configurations. Wouldn't it be better to report something like:

Code: [Select]
Read mode               : Paranoid

instead of:

Code: [Select]
Read mode               : Secure

when the Paranoid mode is activated? At least we'll know that rip has been done with 3 passes. It wouldn't make sense in my opinion to report an identical EAC log, if ripping method is different.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2015-03-02 17:24:27
Why is CUETools saying there are illegal characters in path for this utf-8 .cue?
Code: [Select]
PERFORMER "Hiroyuki Sawano"
TITLE "Attack on Titan Exhibition"
FILE "01 ətˈæk 0N tάɪtn <3Tv>.wav" WAVE
  TRACK 01 AUDIO
    TITLE "ətˈæk 0N tάɪtn <3Tv>"
    PERFORMER "Hiroyuki Sawano"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Call your name <MODv>"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:16:36
FILE "02 Call your name <MODv>.wav" WAVE
    INDEX 01 00:00:00
  TRACK 03 AUDIO
    TITLE "independent奇sayKISS"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:26:15
FILE "03 independent奇sayKISS.wav" WAVE
    INDEX 01 00:00:00
  TRACK 04 AUDIO
    TITLE "ətˈæk 0N tάɪtn <3Tv> (Instrumental)"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:38:61
FILE "04 ətˈæk 0N tάɪtn <3Tv> (Instrumental).wav" WAVE
    INDEX 01 00:00:00
  TRACK 05 AUDIO
    TITLE "Call your name <MODv> (Instrumental)"
    PERFORMER "Hiroyuki Sawano"
    INDEX 00 04:16:36
FILE "05 Call your name <MODv> (Instrumental).wav" WAVE
    INDEX 01 00:00:00
At the same time, it doesn't have any problems reading the same characters in the filenames if I select the files instead?
This is an actual CD (http://vgmdb.net/album/49173) btw, the artist has a weird naming sense.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lvqcl on 2015-03-02 19:26:56
I can see illegal characters '<' and '>' in the 2nd and 5th songs.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-03-02 19:35:09
Same here. The 1st and 4th songs have the full-width characters U+FF1C "<" and U+FF1E ">"
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2015-03-02 20:32:14
They are not illegal - full width characters can be used in NTFS file names. As I said, selecting the corresponding the files that have the same supposedly illegal characters in their filenames work fine.

edit: looks like I misread, you're of course right, for some reason the second and fifth songs have the half-width < > in the .cue (but not on disk). So yes, illegal characters in path indeed.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-03-02 20:43:08
NTFS allows characters that are illegal in Windows APIs.

Ordinary < and > as found in the filenames of track 02 and track 05 are the problem here, not the fullwidth ones. You cannot use Windows APIs to access files with the regular < or > characters in the names under any circumstances, AFAIK.

Can you rename those files? Maybe from within Cygwin or a Linux VM. Ah, I see the problem is just in the .cue. Great!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: a3aan on 2015-03-07 15:31:11
Would it be possible and making sense to have the option to skip re-verifying tracks for which no new data is available at the Accurip and CUETools databases? Cheers.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-03-20 20:43:12
Hello, today I decided to make a test. I splitted a single FLAC image + CUE using Medieval CUE Splitter. I know that it is a shit software and NO-ONE SHOULD BE USING IT (!!!) . Anyway, I only wanted to make a test.
Then I checked the splitted tracks with CUETools, and I received the following message:

Code: [Select]
Padded some input files to a frame boundary.


My question is: how could I fix the splitted tracks so that they will be verifiable again with CUETools? I've tried with Trader's Little Helper, but I'm not sure about which settings to use:

(http://i.snag.gy/9OfEM.jpg)

This is a report of the SBE errors:

Code: [Select]
(01) [Alan Menken & Howard Ashman] Fathoms Below.flac:  audio data is not cut on a sector boundary (sector misalignment = 1616 bytes).
(02) [Alan Menken & Howard Ashman] Main Titles.flac:  audio data is not cut on a sector boundary (sector misalignment = 1024 bytes).
(03) [Alan Menken & Howard Ashman] Fanfare.flac:  audio data is not cut on a sector boundary (sector misalignment = 432 bytes).
(04) [Alan Menken & Howard Ashman] Daughters Of Triton.flac:  audio data is not cut on a sector boundary (sector misalignment = 1440 bytes).
(05) [Alan Menken & Howard Ashman] Part Of Your World.flac:  audio data is not cut on a sector boundary (sector misalignment = 1904 bytes).
(06) [Alan Menken & Howard Ashman] Under The Sea.flac:  audio data is not cut on a sector boundary (sector misalignment = 2224 bytes).
(07) [Alan Menken & Howard Ashman] Part Of Your World (reprise).flac:  audio data is not cut on a sector boundary (sector misalignment = 2112 bytes).
(08) [Alan Menken & Howard Ashman] Poor Unfortunate Souls.flac:  audio data is not cut on a sector boundary (sector misalignment = 1504 bytes).
(09) [Alan Menken & Howard Ashman] Les Poissons.flac:  audio data is not cut on a sector boundary (sector misalignment = 800 bytes).
(10) [Alan Menken & Howard Ashman] Kiss The Girl.flac:  audio data is not cut on a sector boundary (sector misalignment = 1440 bytes).
(11) [Alan Menken & Howard Ashman] Fireworks.flac:  audio data is not cut on a sector boundary (sector misalignment = 2240 bytes).
(12) [Alan Menken & Howard Ashman] Jig.flac:  audio data is not cut on a sector boundary (sector misalignment = 2080 bytes).
(13) [Alan Menken & Howard Ashman] The Storm.flac:  audio data is not cut on a sector boundary (sector misalignment = 176 bytes).
(14) [Alan Menken & Howard Ashman] Destruction Of The Grotto.flac:  audio data is not cut on a sector boundary (sector misalignment = 944 bytes).
(15) [Alan Menken & Howard Ashman] Flotsam And Jetsam.flac:  audio data is not cut on a sector boundary (sector misalignment = 512 bytes).
(16) [Alan Menken & Howard Ashman] Tour Of The Kingdom.flac:  audio data is not cut on a sector boundary (sector misalignment = 1184 bytes).
(17) [Alan Menken & Howard Ashman] Bedtime.flac:  audio data is not cut on a sector boundary (sector misalignment = 240 bytes).
(18) [Alan Menken & Howard Ashman] Wedding Announcement.flac:  audio data is not cut on a sector boundary (sector misalignment = 1232 bytes).
(19) [Alan Menken & Howard Ashman] Eric To The Rescue.flac:  audio data is not cut on a sector boundary (sector misalignment = 1744 bytes).
(20) [Alan Menken & Howard Ashman] Happy Ending.flac:  audio data is not cut on a sector boundary (sector misalignment = 1392 bytes).

There were sector boundary errors.


Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-03-20 20:59:13
TLH can't fix it. Keep in mind that on gapless albums medieval even kills parts of the music away.

Edit: well, TLH can make the frame boundaries fit so that CUEtools don't complain but the original will be different.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-03-20 21:17:38
Quote
how could I fix the splitted tracks so that they will be verifiable again with CUETools?

I've tried this. Some samples are discarded by that program when splitting FLAC files so unless the cuts were made where there was digital silence (zeroes), you likely won't be able to. The TOC layout is usually changed also so the track lengths are also probably wrong.

Even if the cuts were made where there was digital silence and assuming you deleted the original CDImage, you would need to know the original TOC for the CD. Then move samples or pad the missing samples with zeroes to make the track lengths correct and hope you put the correct number on each side of the cut so you don't change the offset of the track. Then it would verify.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-03-20 21:27:29
Thank you, so it seems very painful, if not impossible, to obtain the original tracks once they're splitted with Medieval CUE Splitter, or similar shitty software. So it would be better to ban it from Earth... or simply avoid it! This is because it would be impossible for tracks splitted with MCS to be repaired with CUETools, for example.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2015-03-20 23:34:55
I'm currently running CUETools on WINE and it somewhat works (did not try CUERipper yet), but it's full of weird side effects. For example mounting /tmp as R:\ then attempting to access R:\ via CUETools results in  "The given path's format is not supported". Going via the internal Z: drive gives something similar: "Z:\tmp - the given path's format is not supported". foobar2000 can access the same folder on WINE just fine.

Maybe this was asked before, but why was .NET chosen for CUETools' implementation? Wouldn't it have been better to use something that is portable more easily (or rather, being multi-platform from the start)?  Qt/GTK come to mind.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-03-21 02:54:55
why was .NET chosen for CUETools' implementation? Wouldn't it have been better to use something that is portable more easily (or rather, being multi-platform from the start)?  Qt/GTK come to mind.

Heh, no one would ever complain about Qt or gtk!

CUETools was started as a .NET project by Moitah (http://www.hydrogenaud.io/forums/index.php?showuser=2227) in early 2006, presumably to do stuff he wanted to do, using the programming tools he was familiar with. I don't blame him for not having your needs in mind, nor do I blame Gregory Chudov for not rewriting the whole thing from scratch when he started the fork that everybody uses.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-03-21 03:16:30
"The given path's format is not supported".

This has come up [a href='index.php?act=findpost&pid=881421']here[/a] and [a href='index.php?showtopic=107574']here[/a] and may not be limited to linux under wine. Not sure if Gregory looked into this further.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2015-03-23 12:12:11
The interesting thing is, it can actually write output to it fine, but not browse it.

CUETools was started as a .NET project by Moitah (http://www.hydrogenaud.io/forums/index.php?showuser=2227) in early 2006, presumably to do stuff he wanted to do, using the programming tools he was familiar with. I don't blame him for not having your needs in mind, nor do I blame Gregory Chudov for not rewriting the whole thing from scratch when he started the fork that everybody uses.
I'm not blaming anyone either
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: nakano on 2015-03-28 17:11:07
This is a question about the CueTools DB.
Is there any way to edit my submissions and fix them?

Full info:
Recommended by a friend, I have used the CueRipper CD ripper, but it would always download completely useless data due to mismatching my CDs to more popular ones.
I would frequently correct just the artist and title parameters, because they showed in the file name, and leave the rest as junk data.
Sometimes, I would even just leave all the data and correct the file name alone afterward.
I had no interest in tags or submitting any data, so did not care as the data would never be used or seen by anyone anyway.
Even if I wanted to submit, I did not know what the correct format would be.
(Given 'submit to freeDB' etc. buttons I thought any submissions would have to be made as a manual process.)
But today, I found out that it actually publicly submits tracklists for all CDs you use.
Nearly all the CDs I ripped were labeled as no previous confidence, so my rips are now likely to be shown 100% to others if ever used, junk data and all.
If I knew they would be shown, I would have used more accurate data.
I have looked through what I could understand of the wiki, and through the pages of the DB website.
However, I could not find any way for the users to correct existing submissions.
The CTDB plugin specifically states it does not let you submit metadata, and I could not find any way with CueTools.
Yesterday, I ripped another CD with junk data, and tried correcting it with CueRipper today, but I am told that I have already submitted it, and the data does not change.
I have submitted around 10 unique CDs in the past.
Even if I have to report changes here, is there a way to fix the existing bad data?
One example. (http://db.cuetools.net/?tocid=aVTxYwh0VewTAuudJW4s_8RHrFM-)
Proper data: Original alphabet (Transliterated version)
Correct title: xxxHOLiC 〜四月一日の十六夜草話〜 四月一日の日本文学独り言CD 〜明治編~ (xxxHOLiC ~Watanuki no Izayoi Souwa~: Watanuki no Nihon Bungaku Hitorigoto CD ~Meiji-hen~)
Correct track title: None specified, but the most fitting part of the title is 明治編 (Meiji-hen)
Artist: None specified, but the voice is 四月一日君尋(CV:福山潤) (Kimihiro Watanuki (CV: Jun Fukuyama))
Release date: 2007/AUGUST/09
Country: 日本 (Japan)
Label: Marvelous Entertainment Inc.
Barcode, DiscName, LabelNo: None exists. (N/A)
It has nothing to do with the Spice Girls, but was autodetected as having them on it.
There should also be other colours of CD submitted, a white, black, blue, red, etc, but I can't find them on the website. They will suffer from the same issue.
They also be discs associated to the wrong album information, but I doubt those are easily fixable at all...
I recall that when completing a rip, the drive would show what appeared to be a base64-encoded string, which appears to be associated with the website entry. However, it does not seem to be written to any logs...

Also, for fixing data, what format should be used for data that does not exist in the latin alphabet/ASCII: the original characters in the original language, or a latin transliteration? Previously I have used latin versions to avoid codepage issues, but am now thinking this may be 'the wrong way' to do it. Also, if provided in the original language, should pronunciation guides be included where non-standard pronunciations are used? (This may be an issue only to Japanese.)

Finally, what is uploaded exactly? I delete logs because of containing full paths, and if they are submitted then I will have to use it offline from now on.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-03-28 21:47:41
Quote
This is a question about the CueTools DB.

Next time, there's a separate thread for the [a href='index.php?showtopic=79882']CUETools Database[/a]

Quote
Is there any way to edit my submissions and fix them?

No. The database cannot be edited by the users.

Quote
But today, I found out that it actually publicly submits tracklists for all CDs you use.

No, only the Artist and Album. The track titles displayed in the database are taken from the metadata also stored in the CTDB.

Quote
Yesterday, I ripped another CD with junk data

Couldn't find that rip under the same userid as the example below. The last rip from this userid was 1-6-2015 Detective Conan.

Quote
One example. (http://db.cuetools.net/?tocid=aVTxYwh0VewTAuudJW4s_8RHrFM-)

This example shows Artist: xxxHOLiC PS2, Album: Beige Preorder Disc
Under http://db.cuetools.net/cd/2100525 (http://db.cuetools.net/cd/2100525) the track info is from the stored metadata for 90+ albums. As you click on the different names in the Artist column, you'll see the Artist / Album header, the track Title and the artwork change. If your Artist / Album is not in one of the metadata databases used, you won't find your Track Title here even if you entered it correctly when you ripped the CD. You'll need to submit the CD to one of the databases and it could take up to a month to appear under this record.

Quote
I recall that when completing a rip, the drive would show what appeared to be a base64-encoded string, which appears to be associated with the website entry. However, it does not seem to be written to any logs..

If you mean the CTDB TOCID, that should be in the CUETools log (http://www.cuetools.net/wiki/CUETools_log) (the *.accurip file).

Quote
Finally, what is uploaded exactly?

What information does the database contain per each CD? (http://www.cuetools.net/wiki/CUETools_Database#What_information_does_the_database_contain_per_each_CD.3F)

Note: The example you gave above shows you using CUETools v2.1.2. The CUETools Database was upgraded since that version. v2.1.4 and above are more compatible with the current database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-03-29 03:08:21
Quote
But today, I found out that it actually publicly submits tracklists for all CDs you use.

No, only the Artist and Album. The track titles displayed in the database are taken from the metadata also stored in the CTDB.

I'm confused by that statement. Are you saying that CUERipper submits a partial tracklist, i.e. the TOC (number of tracks and how long each one is), but that the artist & title metadata for each track is never based on info manually entered into CUERipper, and never based on info CUERipper downloaded from other databases based on the TOC? Are CTDB and CUERipper independently fetching track-specific metadata from other databases? i.e. if I submit a new CD and don't have any metadata for it, will its CTDB record have metadata fetched from elsewhere?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-03-29 03:57:37
Now I'm confused.
Along with the other rip info (http://www.cuetools.net/wiki/CUETools_Database#What_information_does_the_database_contain_per_each_CD.3F), only the album's artist and title are submitted to the CTDB. Track titles, track artists or other fields are not submitted to the CTDB, manually edited or not. You can manually edit the album's artist and title to be submitted along with the other rip info but they are not stored as metadata.
When you look up a CD on the CTDB web site (http://db.cuetools.net/) and see Track Titles listed in the record, they were not submitted with the rip info. The Track Titles are retrieved internally from metadata stored in another part of the database. The CTDB stored metadata is exactly the same metadata available to CUETools and CUERipper.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lazlo Nibble on 2015-04-11 20:35:53
Noted in 2.1.5 and the current build of 2.1.6: the .accurip log file generated after a repair+encode omits the CTDB TOCID/CTDB Status block at the start of the file:

Code: [Select]
[CUETools log; Date: 4/11/2015 13:17:47; Version: 2.1.6]
CUETools DB: corrected 26210 errors.
[AccurateRip ID: 002561a5-01d5a130-070d7811] found.
Track  [  CRC  |  V2  ] Status
 01    [065d1415|7f440f66] (077+053/160) Accurately ripped
 02    [2d870c2d|72ef4b1b] (078+053/162) Accurately ripped
 03    [7e367f83|d1c0c3d8] (068+044/158) Accurately ripped
 04    [b4ce9635|ece1c7d0] (068+045/159) Accurately ripped
 05    [e7c5c5e7|36d2bb76] (067+046/159) Accurately ripped
 06    [d4fa7ccf|1455b26e] (068+045/159) Accurately ripped
 07    [5d6ddb30|c8d636bf] (067+046/160) Accurately ripped
 08    [62b7d595|ae3d11ae] (067+048/161) Accurately ripped
 09    [75db0203|194f3c8c] (068+047/161) Accurately ripped
 10    [d76741dd|8d236cfc] (078+054/162) Accurately ripped
 11    [433fa03d|dfb9b849] (078+055/164) Accurately ripped
 12    [49f3cb61|cad43aa5] (078+054/162) Accurately ripped
 13    [a5d6f8f1|b0d6e209] (067+047/160) Accurately ripped
 14    [a586ee03|8ea9e45a] (074+054/159) Accurately ripped
 15    [a7d339bf|22023d90] (067+047/160) Accurately ripped
 16    [442bbd29|d0adb956] (066+048/160) Accurately ripped
 17    [b101537f|5e1a252f] (074+055/159) Accurately ripped
Offsetted by -664:
 01    [040939ae] (007/160) Accurately ripped
 02    [4c8c6d5b] (008/162) Accurately ripped
 03    [35db0bb4] (006/158) Accurately ripped
 04    [d874ba05] (006/159) Accurately ripped
 05    [89914b17] (006/159) Accurately ripped
 06    [9e8db0a7] (006/159) Accurately ripped
 07    [0b6427a8] (006/160) Accurately ripped
 08    [945d1835] (006/161) Accurately ripped
 09    [6d3412db] (006/161) Accurately ripped
 10    [2113b0fc] (007/162) Accurately ripped
 11    [69c1f62a] (008/164) Accurately ripped
 12    [4dd1960b] (007/162) Accurately ripped
 13    [6d7e99ae] (006/160) Accurately ripped
 14    [9cf4e470] (008/159) Accurately ripped
 15    [29e117fb] (006/160) Accurately ripped
 16    [5a0d6d91] (006/160) Accurately ripped
 17    [f7dcceb4] (007/159) Accurately ripped
Offsetted by -36:
 01    [628ca64f] (000/160) No match (V2 was not tested)
 02    [f259456d] (000/162) No match (V2 was not tested)
 03    [fd9a42a5] (000/158) No match (V2 was not tested)
 04    [d1e9bcb7] (000/159) No match (V2 was not tested)
 05    [4724aad5] (000/159) No match (V2 was not tested)
 06    [de5d74d3] (000/159) No match (V2 was not tested)
 07    [a92c8f24] (000/160) No match (V2 was not tested)
 08    [f1bf4085] (000/161) No match (V2 was not tested)
 09    [ef37bd87] (000/161) No match (V2 was not tested)
 10    [376a1af5] (000/162) No match (V2 was not tested)
 11    [bee8415d] (000/164) No match (V2 was not tested)
 12    [7b0414b6] (000/162) No match (V2 was not tested)
 13    [fb7960f3] (000/160) No match (V2 was not tested)
 14    [c257c9ca] (000/159) No match (V2 was not tested)
 15    [735c305d] (000/160) No match (V2 was not tested)
 16    [0dd6d185] (000/160) No match (V2 was not tested)
 17    [530d91f5] (000/159) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [1D435E99] [758DB2C1] [E47866B8]
 01  92.2 [C6603189] [D3D7F263]         
 02  96.9 [E58E8B03] [AC624979]         
 03  90.6 [CD12F4E8] [7FEA0E00]         
 04  95.9 [FDAFB014] [0D109512]         
 05  100.0 [6A60EEF8] [4593A2D7]         
 06  100.0 [705DB54D] [8B6F7522]         
 07  100.0 [B6A9C753] [E25F9092]         
 08  100.0 [5E61FF1E] [23DED61C]         
 09  98.7 [C9677DD4] [48DC52A6]         
 10  100.0 [5F1FBC57] [49BE50F7]         
 11  99.6 [822D30B0] [B6AB457E]         
 12  100.0 [1621AAF0] [6634998B]         
 13  100.0 [22C47B50] [A8418F42]         
 14  100.0 [EA811FE5] [F782BD8D]         
 15  100.0 [C0D9E7BE] [FA7BD434]         
 16  100.0 [3F0C9AE9] [05CBDC12]         
 17  100.0 [FD346B2F] [990993AC]         
Manually running a verify on the repaired file results in an .accurip log that includes the CTDB info, but is otherwise identical to the first:

Code: [Select]
[CUETools log; Date: 4/11/2015 13:18:50; Version: 2.1.6]
[CTDB TOCID: 7mWblN0RDFC9wZ3HbM8S8VhQD.A-] found.
Track | CTDB Status
  1  | (52/52) Accurately ripped
  2  | (52/52) Accurately ripped
  3  | (42/52) Accurately ripped, or (10/52) differs in 1 samples @00:04:71
  4  | (42/52) Accurately ripped, or (10/52) differs in 26177 samples @00:13:27-00:13:69
  5  | (42/52) Accurately ripped, or (10/52) differs in 4 samples @04:06:36,04:06:48,04:06:58,04:06:74
  6  | (41/52) Accurately ripped, or (10/52) differs in 2 samples @02:43:28-02:43:30
  7  | (41/52) Accurately ripped, or (10/52) differs in 1 samples @04:47:48
  8  | (42/52) Accurately ripped, or (10/52) differs in 19 samples @02:36:50-02:36:52,02:36:60,02:37:12,02:37:40-02:37:44,02:37:51,02:37:63-02:37:65,02:38:03,02:38:41-02:38:46,02:38:53-02:38:59,02:38:66-02:38:69
  9  | (42/52) Accurately ripped, or (10/52) differs in 3 samples @03:22:35,03:22:60,03:23:63
 10  | (52/52) Accurately ripped
 11  | (52/52) Accurately ripped
 12  | (52/52) Accurately ripped
 13  | (42/52) Accurately ripped, or (10/52) differs in 1 samples @00:00:16
 14  | (52/52) Accurately ripped
 15  | (42/52) Accurately ripped, or (10/52) differs in 1 samples @02:29:62
 16  | (42/52) Accurately ripped, or (10/52) differs in 1 samples @02:45:02
 17  | (52/52) Accurately ripped
[AccurateRip ID: 002561a5-01d5a130-070d7811] found.
Track  [  CRC  |  V2  ] Status
 01    [065d1415|7f440f66] (077+053/160) Accurately ripped
 02    [2d870c2d|72ef4b1b] (078+053/162) Accurately ripped
 03    [7e367f83|d1c0c3d8] (068+044/158) Accurately ripped
 04    [b4ce9635|ece1c7d0] (068+045/159) Accurately ripped
 05    [e7c5c5e7|36d2bb76] (067+046/159) Accurately ripped
 06    [d4fa7ccf|1455b26e] (068+045/159) Accurately ripped
 07    [5d6ddb30|c8d636bf] (067+046/160) Accurately ripped
 08    [62b7d595|ae3d11ae] (067+048/161) Accurately ripped
 09    [75db0203|194f3c8c] (068+047/161) Accurately ripped
 10    [d76741dd|8d236cfc] (078+054/162) Accurately ripped
 11    [433fa03d|dfb9b849] (078+055/164) Accurately ripped
 12    [49f3cb61|cad43aa5] (078+054/162) Accurately ripped
 13    [a5d6f8f1|b0d6e209] (067+047/160) Accurately ripped
 14    [a586ee03|8ea9e45a] (074+054/159) Accurately ripped
 15    [a7d339bf|22023d90] (067+047/160) Accurately ripped
 16    [442bbd29|d0adb956] (066+048/160) Accurately ripped
 17    [b101537f|5e1a252f] (074+055/159) Accurately ripped
Offsetted by -664:
 01    [040939ae] (007/160) Accurately ripped
 02    [4c8c6d5b] (008/162) Accurately ripped
 03    [35db0bb4] (006/158) Accurately ripped
 04    [d874ba05] (006/159) Accurately ripped
 05    [89914b17] (006/159) Accurately ripped
 06    [9e8db0a7] (006/159) Accurately ripped
 07    [0b6427a8] (006/160) Accurately ripped
 08    [945d1835] (006/161) Accurately ripped
 09    [6d3412db] (006/161) Accurately ripped
 10    [2113b0fc] (007/162) Accurately ripped
 11    [69c1f62a] (008/164) Accurately ripped
 12    [4dd1960b] (007/162) Accurately ripped
 13    [6d7e99ae] (006/160) Accurately ripped
 14    [9cf4e470] (008/159) Accurately ripped
 15    [29e117fb] (006/160) Accurately ripped
 16    [5a0d6d91] (006/160) Accurately ripped
 17    [f7dcceb4] (007/159) Accurately ripped
Offsetted by -36:
 01    [628ca64f] (000/160) No match (V2 was not tested)
 02    [f259456d] (000/162) No match (V2 was not tested)
 03    [fd9a42a5] (000/158) No match (V2 was not tested)
 04    [d1e9bcb7] (000/159) No match (V2 was not tested)
 05    [4724aad5] (000/159) No match (V2 was not tested)
 06    [de5d74d3] (000/159) No match (V2 was not tested)
 07    [a92c8f24] (000/160) No match (V2 was not tested)
 08    [f1bf4085] (000/161) No match (V2 was not tested)
 09    [ef37bd87] (000/161) No match (V2 was not tested)
 10    [376a1af5] (000/162) No match (V2 was not tested)
 11    [bee8415d] (000/164) No match (V2 was not tested)
 12    [7b0414b6] (000/162) No match (V2 was not tested)
 13    [fb7960f3] (000/160) No match (V2 was not tested)
 14    [c257c9ca] (000/159) No match (V2 was not tested)
 15    [735c305d] (000/160) No match (V2 was not tested)
 16    [0dd6d185] (000/160) No match (V2 was not tested)
 17    [530d91f5] (000/159) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  100.0 [1D435E99] [758DB2C1] [E47866B8]
 01  92.2 [C6603189] [D3D7F263]         
 02  96.9 [E58E8B03] [AC624979]         
 03  90.6 [CD12F4E8] [7FEA0E00]         
 04  95.9 [FDAFB014] [0D109512]         
 05  100.0 [6A60EEF8] [4593A2D7]         
 06  100.0 [705DB54D] [8B6F7522]         
 07  100.0 [B6A9C753] [E25F9092]         
 08  100.0 [5E61FF1E] [23DED61C]         
 09  98.7 [C9677DD4] [48DC52A6]         
 10  100.0 [5F1FBC57] [49BE50F7]         
 11  99.6 [822D30B0] [B6AB457E]         
 12  100.0 [1621AAF0] [6634998B]         
 13  100.0 [22C47B50] [A8418F42]         
 14  100.0 [EA811FE5] [F782BD8D]         
 15  100.0 [C0D9E7BE] [FA7BD434]         
 16  100.0 [3F0C9AE9] [05CBDC12]         
 17  100.0 [FD346B2F] [990993AC]         
This is with Advanced Settings > AccurateRip > Log File > Verbose checked.

Also, the straight "verify" in 2.1.6 leaves out the summary block generated by "verify" in 2.1.5:

Code: [Select]
[CUETools log; Date: 4/11/2015 13:43:20; Version: 2.1.5]
[CTDB TOCID: 7mWblN0RDFC9wZ3HbM8S8VhQD.A-] found.
        [ CTDBID ] Status
        [cee53527] (40/52) Accurately ripped
        [5868242b] (10/52) Differs in 26210 samples @07:42:53,11:06:39-11:07:06,18:39:06,18:39:18,18:39:28,18:39:44,21:25:20-21:25:22,26:16:70,28:56:62-28:56:64,28:56:72,28:57:24,28:57:52-28:57:56,28:57:63,28:58:00-28:58:02,28:58:15,28:58:53-28:58:58,28:58:65-28:58:71,28:59:03-28:59:06,32:23:37,32:23:62,32:24:65,43:33:33,51:45:32,54:32:69
        [e764895c] (01/52) No match
        [ff2a9764] (01/52) No match
Track | CTDB Status
  1  | (52/52) Accurately ripped
  2  | (52/52) Accurately ripped
[... rest omitted; identical to previous block ...]
(Thanks for CTDB. It's let me assemble clean rips of some completely-impossible-to-replace discs that I've been fighting with in some cases for years.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-04-11 23:14:13
The first one, the repair script has always behaved that way.

The last one you need to set
Advanced Settings > Advanced > CTDB > Detailed log = True
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lazlo Nibble on 2015-04-12 18:48:30
The first one, the repair script has always behaved that way.

The last one you need to set
Advanced Settings > Advanced > CTDB > Detailed log = True

For the first, are you saying it's an intentional decision NOT to include the CTDB data for an image in the log after a repair?  If so, what's the rationale for that?

For the second, I already have Detailed Log set to True in the Advanced tab on 2.1.6.  But it's behaving inconsistently -- I just re-ran a verify in 2.1.6 against the same source file as the second code block above and this time it included the four CTDBID entries before the per-track status.  If there's any additional information I can provide if I manage to reproduce it again please let me know.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-04-12 20:15:13
1. CUETools doesn't re-verify after the repair. The AccurateRip confidence levels in the result log are just a projection of what should be. When the CTDB was created, most of the data came from AccurateRip. There was hope for a closer integration which would allow the database to update confidence numbers directly from AccurateRip. When it became clear that there would be no integration, all the confidence levels based on AccurateRip results were removed and the CTDB began storing independent submissions.
It would be nice to have an option to re-verify after repair rather than verifying again as a separate action.

2. Are you using Profiles? (upper left of GUI). If so check the setting in each profile.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: blindmelon on 2015-04-18 17:03:47
Hello,


I've just downloaded CUETools (2.1.5) and it just don't run. It only pops window "CUE Tools has encountered a problem and needs to close.  We are sorry for the inconvenience." and nothing else happens. I'm runnin XP SP3, .NET Fw 2.0 installed, also the Visual C 2008. Not sure if I'm missing something or what to do. I've tried 2.1.4, got same result. Same with CUERipper.

Any suggestions? Help please. Thank you

blindmelon
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-04-19 06:19:54
It only pops window "CUE Tools has encountered a problem and needs to close.  We are sorry for the inconvenience." and nothing else happens.


FWIW I get the same thing on one Windows 7 computer. Don't know why. Didn't care enough to find out.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-04-21 02:30:05
I updated my nVidia GT650M drivers, and now when I try to encode to FLAC with CUETools on Windows 7 Professional x64 using FLACCL, I get a "no opencl platforms found" error... What happened?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: antigeek on 2015-04-26 18:42:15
regarding usage of "CUETools.ConsoleRipper.exe" under windows (v2.1.6), a very nice application btw
ripping an audio cd with 'illegal' characters in musicbrainz album title (in my case esp. ':')  throws an error
cuetools has this 'force ansi filenames / remove special characters' option, and cueripper (gui) does this by itself (no config)...

example:

Code: [Select]
Filename    : Nick Warren - Global Underground 028: Nick Warren in Shanghai.wav
MusicBrainz : Nick Warren - Global Underground 028: Nick Warren in Shanghai
[...]
Error: Das angegebene Pfadformat wird nicht unterstützt.
   bei System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Bo
olean needFullPath)
   bei System.Security.Util.StringExpressionSet.CreateListFromExpressions(String
[] str, Boolean needFullPath)
   bei System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermission
Access access, AccessControlActions control, String[] pathListOrig, Boolean chec
kForDuplicates, Boolean needFullPath, Boolean copyPathList)
   bei System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess
access, AccessControlActions control, String[] pathList, Boolean checkForDuplic
ates, Boolean needFullPath)
   bei System.IO.FileStream.Init(String path, FileMode mode, FileAccess access,
Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions
options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean
bFromProxy)
   bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options)
   bei System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encodi
ng, Int32 bufferSize)
   bei System.IO.StreamWriter..ctor(String path)
   bei CUETools.ConsoleRipper.Program.Main(String[] args)


would be nice if that got fixed
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2015-04-28 04:08:13
Hey:

Three questions:
1) AFAIU, CUE Ripper never reads into lead in/out (even if the drive supports it) and cannot be configured to do so, right?
So it will all always loose some tiny bit of data (depending on the drive's offset)?!


2) The documentation of CUERipper says it would use C2 Errors, but in the EAC-Style log it writes:
""
even though my drive supports C2, errors.
So what's the case now?


3) IIRC, e.g. dBpoweramp's CD Ripper, when AccurateRip is enabled (and the CD found in the DB), it trusts whatever AccruateRip says (possibly ignoring C2 errors?)... so the question is whether CUETools would still give me an error notice when C2 errors occur, even when Accurate Rip and/or CTDB say everything would be fine (which may be wrong).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-04-28 04:59:37
1) Correct. CUERipper does not Overread (as EAC puts it) into Lead-In and Lead-Out. The tiny bit of lost data is usually silence or inaudible.

2) The 'Make use of C2 pointers' in the EAC log shows the condition of the setting (not that the drive actually supports using it). The EAC-style log in CUERipper always shows 'No'. CUERipper does not have the setting like EAC does.

3) The 'Error Correction Progress Bar' will light up red on both read errors and C2 errors (if C2 is detected as supported by the drive). This happens during the extraction process before the track is verified against the databases. If the errors continue after maximum retries, suspicious positions are added to the extraction log. It is possible in some cases that the data read was correct despite the errors and the track will match as accurate in one or both of the databases.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: r3n4m3 on 2015-04-28 09:02:16
I updated my nVidia GT650M drivers, and now when I try to encode to FLAC with CUETools on Windows 7 Professional x64 using FLACCL, I get a "no opencl platforms found" error... What happened?

Change my videocard nVidia GTS 250 to GTX 560, and still have the same problem.

Cant choose platform in encoding settings.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-05-10 10:29:32
I'm at a loss to explain this behavior.

The first two tracks of this CD won't rip without error; the disc is scratched. If I verify it in CUETools, this is the result, and all looks as expected:

Code: [Select]
[CUETools log; Date: 5/10/2015 2:53:20 AM; Version: 2.1.6]
Pregap length 00:00:33.
[CTDB TOCID: DqV4otplMQna3r1yiIUcO4vTqqw-] found.
Track | CTDB Status
  1  | (0/4) No match
  2  | (0/4) No match
  3  | (4/4) Accurately ripped
  4  | (4/4) Accurately ripped
  5  | (4/4) Accurately ripped
  6  | (4/4) Accurately ripped
  7  | (4/4) Accurately ripped
  8  | (4/4) Accurately ripped
  9  | (4/4) Accurately ripped
 10  | (4/4) Accurately ripped
 11  | (4/4) Accurately ripped
[AccurateRip ID: 00118b1a-009bfbba-790ac80b] found.
Track  [  CRC  |  V2  ] Status
 01    [4b30b38e|582fbdbf] (00+00/42) No match
 02    [39b37393|14c0e4cd] (00+00/44) No match
 03    [f51007bc|7a0c1d87] (26+17/46) Accurately ripped
 04    [57da509b|55140fe1] (26+16/45) Accurately ripped
 05    [24a80837|1b4cd5fb] (26+16/45) Accurately ripped
 06    [9545ee68|5959c1bb] (26+16/45) Accurately ripped
 07    [7eefe863|9726ea17] (25+16/44) Accurately ripped
 08    [7b1fe777|c8d86c1d] (27+16/46) Accurately ripped
 09    [dcfad4f9|5843ac87] (26+16/45) Accurately ripped
 10    [dcca73f3|d8e9d490] (25+16/44) Accurately ripped
 11    [f873119d|b6f136f1] (27+16/46) Accurately ripped
Offsetted by -86:
 01    [b1a7d225] (00/42) No match (V2 was not tested)
 02    [cd78c0a8] (00/44) No match (V2 was not tested)
 03    [a0fac487] (00/46) No match (V2 was not tested)
 04    [ab10cbea] (00/45) No match (V2 was not tested)
 05    [267212e4] (00/45) No match (V2 was not tested)
 06    [0f7f3add] (00/45) No match (V2 was not tested)
 07    [9cf4e464] (00/44) No match (V2 was not tested)
 08    [1b650a39] (00/46) No match (V2 was not tested)
 09    [f54879f4] (00/45) No match (V2 was not tested)
 10    [4f6deaba] (00/44) No match (V2 was not tested)
 11    [cf775937] (00/46) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL]
 --  90.2 [CA318393] [9068CFF3]         
 01  83.8 [85C5F99E] [472CABB2]         
 02  71.4 [0C808900] [70637A5E]         
 03  65.9 [A16B8A7B] [A1A0FF66]         
 04  56.8 [B09FA008] [800D2190]         
 05  56.9 [CFE732AE] [C35DB6F1]         
 06  88.5 [1026E056] [8019D8CF]         
 07  84.9 [1256311D] [BB3F2F03]         
 08  71.3 [78956AFC] [09799AD5]         
 09  72.6 [4BC68E1B] [0BE858FD]         
 10  90.2 [9C7B1032] [585584A0]         
 11  48.4 [1BE9593A] [2CCD1353]         

All is normal... those two tracks are showing as "No Match" in CTDB, ARv1, ARv2.

But if I replace those two tracks with files from someone else's rip (I'm hoping his rip is good) and I verify everything again, the result is bizarre:

Code: [Select]
[CUETools log; Date: 5/10/2015 3:02:52 AM; Version: 2.1.6]
Pregap length 00:00:33.
[CTDB TOCID: DqV4otplMQna3r1yiIUcO4vTqqw-] found.
Track | CTDB Status
  1  | (4/4) Accurately ripped
  2  | (4/4) Differs in 9 samples @00:00:32
  3  | (4/4) Differs in 11 samples @00:00:32
  4  | (4/4) Accurately ripped
  5  | (4/4) Accurately ripped
  6  | (4/4) Accurately ripped
  7  | (4/4) Accurately ripped
  8  | (4/4) Accurately ripped
  9  | (4/4) Accurately ripped
 10  | (4/4) Accurately ripped
 11  | (4/4) Accurately ripped
[AccurateRip ID: 00118b1a-009bfbba-790ac80b] found.
Track  [  CRC  |  V2  ] Status
 01    [bff168d5|d23517ae] (00+00/42) No match
 02    [7e54af3d|59c11c5f] (00+00/44) No match
 03    [f51007bc|7a0c1d87] (26+17/46) Accurately ripped
 04    [57da509b|55140fe1] (26+16/45) Accurately ripped
 05    [24a80837|1b4cd5fb] (26+16/45) Accurately ripped
 06    [9545ee68|5959c1bb] (26+16/45) Accurately ripped
 07    [7eefe863|9726ea17] (25+16/44) Accurately ripped
 08    [7b1fe777|c8d86c1d] (27+16/46) Accurately ripped
 09    [dcfad4f9|5843ac87] (26+16/45) Accurately ripped
 10    [dcca73f3|d8e9d490] (25+16/44) Accurately ripped
 11    [f873119d|b6f136f1] (27+16/46) Accurately ripped
Offsetted by -86:
 01    [9c98b5ee] (00/42) No match (V2 was not tested)
 02    [0791630b] (00/44) No match (V2 was not tested)
 03    [a1e3c3d8] (00/46) No match (V2 was not tested)
 04    [ab10cbea] (00/45) No match (V2 was not tested)
 05    [267212e4] (00/45) No match (V2 was not tested)
 06    [0f7f3add] (00/45) No match (V2 was not tested)
 07    [9cf4e464] (00/44) No match (V2 was not tested)
 08    [1b650a39] (00/46) No match (V2 was not tested)
 09    [f54879f4] (00/45) No match (V2 was not tested)
 10    [4f6deaba] (00/44) No match (V2 was not tested)
 11    [cf775937] (00/46) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL]
 --  90.2 [E5AB8A7E] [361E403E]         
 01  83.8 [6259B2FA] [7096D898]         
 02  45.7 [0BD59295] [1E9ED238]         
 03  65.9 [A16B8A7B] [A1A0FF66]         
 04  56.8 [B09FA008] [800D2190]         
 05  56.9 [CFE732AE] [C35DB6F1]         
 06  88.5 [1026E056] [8019D8CF]         
 07  84.9 [1256311D] [BB3F2F03]         
 08  71.3 [78956AFC] [09799AD5]         
 09  72.6 [4BC68E1B] [0BE858FD]         
 10  90.2 [9C7B1032] [585584A0]         
 11  48.4 [1BE9593A] [2CCD1353]         

ARv1 & ARv2 are still saying no match (so at least 1 sample is wrong), but CTDB is saying track 1 is actually OK, while tracks 2 and 3 are slightly wrong.

What's going on? I didn't touch track 3 at all...I only replaced the files for tracks 1 and 2! How can track 3 now be wrong, only in CTDB?

The first 50000 samples in tracks 1 & 2 of my rip are identical to his rip, so how can track 2 go from No Match to being off by only 9 samples, 32 frames in?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-05-10 14:04:43
I know you said the first second or so of the files are identical but maybe something in the imported tracks is throwing the offset-finding checksum off?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2015-05-10 22:22:15
It looks suspiciously like my calculations when displaying this log are off by a pregap length (33 frames). Then the bad sectors aren't actually at 0:32, but at -0:01, i.e. in the last sector of the first two tracks.
I'll have to check it. You can go ahead and repair this rip, i'm pretty sure that would work and you'll find that the difference was indeed in the track ends.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-05-11 03:57:06
Ah, you're right. A repair worked, and the difference was indeed at the ends of those tracks.

It was my own fault. The other guy's files were offset by 18 samples, so this is what I attempt to do before the verify:

Something went wrong, though; I must've gotten confused as to which files I was editing. The 18 samples I ended up putting at the end of each track were not the right ones. Oh well, all is fine now after the repair.

Can the log calculation bug affect whether a rip is determined to be repairable? i.e. could a repairable rip be mistakenly determined to be unrepairable?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2015-05-11 04:22:26
I think this is just a log issue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Krelgprmnkfgszha on 2015-05-11 22:17:17
Recently files I split with CUETools 2.1.6 sometimes have a lower CTDBDISCCONFIDENCE tag than all CTDBTRACKCONFIDENCE tags. The track confidence tags seem to be correct, they're the same as in the .accurip file.

Examples:
1. All tracks have track confidence (and CTDBTRACKCONFIDENCE tag) 2/2, CTDBDISCCONFIDENCE is 1/2.
2. Track confidence is 18/18 or 17/18, CTDBDISCCONFIDENCE is 16/18.
3. Track confidence is 61/61 or 59/61, CTDBDISCCONFIDENCE is 33/61.

Did i misunderstand what the CTDBDISCCONFIDENCE tag is or is this a bug, is there any way i can fix this and can i be sure that the track confidences are correct so i could simply change the CTDBDISCCONFIDENCE tag to the lowest track confidence?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-05-11 23:16:59
Did i misunderstand what the CTDBDISCCONFIDENCE tag is?
CTDBDISCCONFIDENCE is based on CTDBID matches. Each CTDBID represents the CRC32 ID of the entire disc. To see the CTDBID in the .accurip file, turn on the Detailed log (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB). In the example below the CTDBDISCCONFIDENCE=93 and the CTDBTRACKCONFIDENCE=101

Code: [Select]
[CUETools log; Date: 5/11/2015 3:55:06 AM; Version: 2.1.6]
[CTDB TOCID: be3uqHSr5yJNFuwxxbrlPBIzcOs-] found.
        [ CTDBID ] Status
        [462d2223] (0[b][color=#FF0000]93[/color][/b]/109) Accurately ripped
        [414f70ae] (007/109) Differs in 224 samples @00:17:40,11:45:38
        [a1144bde] (001/109) No match
        [840af95a] (001/109) No match
        [a2f57795] (001/109) No match
        [1905e7ca] (001/109) No match
        [978f5d54] (001/109) No match
        [84f95ab0] (001/109) No match
        [f437dbed] (001/109) No match
        [6ca4da14] (001/109) No match
        [c30f7b29] (001/109) No match
Track | CTDB Status
  1  | ([b][color=#FF0000]101[/color][/b]/109) Accurately ripped, or (7/109) differs in 44 samples @00:17:40
  2  | ([b][color=#FF0000]101[/color][/b]/109) Accurately ripped, or (7/109) differs in 180 samples @07:17:10
  3  | (109/109) Accurately ripped
  4  | (108/109) Accurately ripped
  5  | (109/109) Accurately ripped
  6  | (108/109) Accurately ripped
  7  | (109/109) Accurately ripped
  8  | (109/109) Accurately ripped
  9  | (109/109) Accurately ripped
 10  | (109/109) Accurately ripped
 11  | (109/109) Accurately ripped
 12  | (108/109) Accurately ripped
 13  | (109/109) Accurately ripped
 14  | (107/109) Accurately ripped
 15  | (108/109) Accurately ripped
 16  | (106/109) Accurately ripped
In each of the other CTDBID's, some of the tracks match the rip but the tracks that don't match are not always the same tracks. That's why the CTDBTRACKCONFIDENCE can be higher.

edit: minor changes; added color
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: digitalharmonic on 2015-05-23 12:43:12
I'm a new CUETools user.

First of all:
Thank you very much for this great tool, CUETools. It's really awesome!

Secondly:
I have a rip of which I know that it's not a perfect rip, as no offset correction was
used although an offset correction of +667 should have been used for a perfect rip.

I tried to turn this rip into a perfect rip, by first of all applying CUETools
encode (fix offset) function to it. I will show the result at the end of this
posting.

I've expected, that this causes 3 things:
- change in offset from 0 to +667

and as a logical consequence of this:
- the first 667 samples of the rip get cut off
- after the last sample of the rip a space in size of 667 samples arises, which will get filled up by null samples/silent samples, so that the complete length of the rip stays the same

Then, judging by the CUETools log file, I thought one can decide, if the rip by
this change already is perfect or not and needs a repair operation for it:
I thought, when accuraterip verifies the result as accurately ripped,
the rip turned into a perfect rip, and if accurate rip says the result
'don't match' then not. And in the latter case, if additionally also CTDB says
that the rip has 'errors' and there is 'repair data' in the CTDB in order
to fix it, that then one can do a second CUETools run where one applies 'repair' function
to the rip with fixed offset and then by this hopefully finally turned the rip
into a perfect rip, indicated by the respective CUETools log file where accurate rip now
says that the rip is 'accurately ripped' and also CTDB considers the rip to be without flaws.

In case the rip turned into a perfect rip just by the 'fix offset' function, so without
a second run for applying 'repair' function, I would have explained that to myself by
assuming, that the cutted away 667 samples were 667 additional null samples/silent samples
generated by missing offset correction and attached before the rip without offset correction,
anyway, so that cutting them away is totally fine, and that in case one had made a rip with
necessary offset correction, then the last 667 samples of the perfect rip would have been
null samples/silent samples, anyway, so that adding 667 null samples/silent samples
to the end of the rip without offset correction is also just fine.

So much to my understanding, now the CUETools log file of the first CUETools run,
the 'fix offset' run:

Code: [Select]
[CUETools log; Date: 23.05.2015 11:40:06; Version: 2.1.5]
Pregap length 00:00:33.
Offset applied: 667
[CTDB TOCID: pEqv9TiawaE1tmQwqS4BRRoonrY-] found.
Track | CTDB Status
  1   | (7/7) Accurately ripped
  2   | (7/7) Accurately ripped
[AccurateRip ID: 0000c818-000211c7-0901ba02] found.
Track   [  CRC   |   V2   ] Status
01     [acc75a05|0dbc29d1] (43+23/95) Accurately ripped
02     [f11833ee|5773840c] (43+23/95) Accurately ripped
Offsetted by -1015:
01     [f3b003d9] (11/95) Accurately ripped
02     [cd25a9b4] (11/95) Accurately ripped
Offsetted by -669:
01     [a5e7e666] (05/95) Accurately ripped
02     [4093b297] (05/95) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   99,9 [CFAB0DE2] [42E1D8DC]   CRC32   : offset -667
01   99,9 [1672060F] [7EEB2F51]          
02   99,8 [2D84EB79] [CFAA0A58]


My problem with this result is, that to me it doesn't make sense:
The CUETools log file tells me that offset correction of +667 was applied,
but to my understanding this actually can't happen without the other
2 things mentioned above:
Firstly cutting the first 667 samples of the rip, and secondly,
adding 667 null samples/silent samples after the end of the rip.
So, what i was expecting and what is just logic to me is, that
the CUETools log file not only contains the line 'Offset applied: 667', but also
additionally the lines 'Truncated 667 extra samples in some input files'
and 'Padded some (667) input files to a frame boundary', but it
only contains 'Offset applied: 667' and not the other both mentioned lines.

CUETools log file tells me 'I've corrected offset without cutting or adding anything
regarding the rip', which for me sounds like 'I've took a shower but didn't
become wet'.
So, how come, that the both lines 'Truncated 667 extra samples in some input files'
and 'Padded some (667) input files to a frame boundary' are missing in the CUETools log file?
Can't wrap my mind around it.
I also tried to apply 'fix offset' function not only automatically, but
also manually, but the CUETools log file is the same in both approaches.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-05-23 14:22:40
If applying Offset correction to the input file(s) means you discard samples from one end of the rip and add null samples to the other end then why isn't 'Offset applied: xxx' sufficient?

CUETools reports "Truncated 4608 extra samples in some input files" only when it detects the presence of an extra 4608 samples at the end of one or more of the input files (that might be added by some FLAC encoders) and removes those extra samples.

CUETools reports "Padded some input files to a frame boundary" when one or more of the input files are missing samples and do not align on a frame boundary. 

Applying Offset correction to the file(s) does not make your rip any better and really isn't necessary.

Code: [Select]
Offsetted by -1015:
01    [f3b003d9] (11/95) Accurately ripped
02    [cd25a9b4] (11/95) Accurately ripped
Offsetted by -669:
01    [a5e7e666] (05/95) Accurately ripped
02    [4093b297] (05/95) Accurately ripped
All tracks "Accurately ripped" means your rip is fine.
If you want to verify your rip at a different offset simply put that value in the 'Offset' box under the 'Extra' section. The offset is applied to 'Verify' without changing the file(s). Just remember to put '0' (zero) back in the box when finished.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lvqcl on 2015-05-23 14:45:21
CUETools reports "Truncated 4608 extra samples in some input files" only when it detects the presence of an extra 4608 samples at the end of one or more of the input files (that might be added by some FLAC encoders) and removes those extra samples.

IIRC there was a setting in EAC when it adds 4608 samples to a track as a workaround for some buggy MP3 encoders.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: digitalharmonic on 2015-05-25 20:16:03
If applying Offset correction to the input file(s) means you discard samples from one end of the rip and add null samples to the other end then why isn't 'Offset applied: xxx' sufficient?
That's a good point. I assumed it was not sufficient because of the existance of the other both ... and my understanding of it; that implicated incompleteness or something absurd in the described case. If the other both didn't exist, or I had the understanding of them,
like you've explained it, or if I found this explanation in the wiki documentation of CUETools, I basically wouldn't have considered 'Offset applied: xxx' insufficient.

CUETools reports "Truncated 4608 extra samples in some input files" only when it detects the presence of an extra 4608 samples at the end of one or more of the input files (that might be added by some FLAC encoders) and removes those extra samples.
Ah, so this line refers to something else than fixing a rip like described.
Well, if this is the case, I surely can renounce this line. Problem solved half way. Thank you.

CUETools reports "Padded some input files to a frame boundary" when one or more of the input files are missing samples and do not align on a frame boundary.
But isn't this only (!) the case, when you perform the fix offset function?
I think your explanation so far made it clear enough, that the missing of the "Truncated 4608 extra samples in some input files" line is not weird at all in the context of described procedure,
but I can't say that so far from the "Padded some input files to a frame boundary" line, even after reading this explanation; it still sounds to me like something, which existance and absense in the
CUETools log file of a 'fix offset' operation implicates incompleteness or absurdity. To make it more clear: If the adding of null samples/silent samples in the process of a 'fix offset' operation
already is implicated by the line 'Offset applied: xxx', then how comes, the line "Padded some input files to a frame boundary" exist in the first place? Isn't that redundant then?

Applying Offset correction to the file(s) does not make your rip any better and really isn't necessary.
I guess that you're right in practice, but not when archive quality is the aim.


Code: [Select]
Offsetted by -1015:
01    [f3b003d9] (11/95) Accurately ripped
02    [cd25a9b4] (11/95) Accurately ripped
Offsetted by -669:
01    [a5e7e666] (05/95) Accurately ripped
02    [4093b297] (05/95) Accurately ripped
All tracks "Accurately ripped" means your rip is fine.
If you want to verify your rip at a different offset simply put that value in the 'Offset' box under the 'Extra' section. The offset is applied to 'Verify' without changing the file(s).
But isn't the 'fix offset' function also applied for creating a new music file or new group of music files as an output, which has a different offset than the offset of the input file(s)?

Just remember to put '0' (zero) back in the box when finished.
Where's the point in doing that, when one knows that the offset of the input file(s) is wrong, and the output file(s) is correct?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Goratrix on 2015-05-25 20:35:09
But isn't this only (!) the case, when you perform the fix offset function?


No, it's not. You get the same message (and action) when you take a not-proper rip (one with either missing or redundant samples that do not correspond to a correct frame boundary) and simply encode it, without changing offset.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-05-25 21:13:42
If the adding of null samples/silent samples in the process of a 'fix offset' operation
already is implicated by the line 'Offset applied: xxx', then how comes, the line "Padded some input files to a frame boundary" exist in the first place? Isn't that redundant then?

"Padded some input files to a frame boundary" is reported when the INPUT file(s) are missing some samples and do not align on a Compact Disc Digital Audio (http://en.wikipedia.org/wiki/Red_Book_%28audio_CD_standard%29) frame boundary due to some type of damage or source material not from a CD.

Edit: Goratrix beat me to it.

I guess that you're right in practice, but not when archive quality is the aim.

The quality doesn't change but samples are discarded.

But isn't the 'fix offset' function also applied for creating a new music file or new group of music files as an output, which has a different offset than the offset of the input file(s)?

I was providing an alternate to misusing the 'fix offset' script to change the offset of the file(s) just to verify against the AR database.

Where's the point in doing that, when one knows that the offset of the input file(s) is wrong, and the output file(s) is correct?

Because if you don't return the value in the Offset box to '0' (zero) in the Extra section (http://www.cuetools.net/wiki/CUETools_Settings#.2811.29_Extra_.7Bsection.7D), the nonzero offset in that box will also be applied to future rips you verify or encode.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: digitalharmonic on 2015-05-27 10:24:06
Thank you for your answers, Goratrix and korth,
and thank you for your patience, korth.

So, the 'fix offset' function is just a verification thing and
can't be used as a tool, to create new music files with different offset,
and even if one could use it as this, it wouldn't make a difference
in terms of practice and archiving.
To be honest, that doesn't surprise me so much, as this notion of
changing offset of music files afterwards and in combination with the
repair function if necessary after that step repairing them sounded like magic ^^ ...

But what leaves me puzzled is the offset thing: If it doesn't matter like discribed,
then why all this hazzle exist around it with 'oh, you got to change offset to XXX !'
and so ?
I mean what you basically say is 'forget the offset thing while ripping and afterwards.
Even if one wants a perfect rip, it's a complete waste of time to deal with it.'
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-05-27 23:40:49
I didn't say 'fix offset' couldn't be used to create new music files with a different offset, I said it wasn't necessary to use the script to alter the files just to verify in the AR database (see pressings (http://wiki.hydrogenaud.io/index.php?title=AccurateRip#Pressings)).

It isn't necessary to use the 'fix offset' script prior to running the 'repair' script either. The CTDB recovery record doesn't care about the offset.
Here's an [a href='index.php?act=findpost&pid=108678']example[/a] of when applying an offset could be helpful.
The correct 'read offset' is so everyone gets the same data, even when using different hardware. If the read offset wasn't set, it is similar to having a pressing (http://wiki.hydrogenaud.io/index.php?title=AccurateRip#Pressings) that no one else has yet submitted to the AR database. Unless there is a problem with correct playback as in the example above, there's no real need to fix it. But if it makes you feel warm and fuzzy to correct the offset to what should've been set in the software then you'll just discard a few milliseconds from one end of the rip (also see the [a href='index.php?act=findpost&pid=819468']developer's comments[/a]).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-05-28 00:59:47
Correct [a href='index.php?act=findpost&pid=892908']example[/a] link for previous post. (I must've entered a topic ID for a post ID).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Freyard on 2015-05-28 10:59:57
Hello all! I have CUE Tools 2.1.4 installed in my system and I cannot find a way to uninstall it. I have looked in the folder where all the files are installed and I have looked under the Uninstall or Change a Program directory in Control Panel. None have an option to uninstall CUE Tools, which is a little frustrating. Please help!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2015-05-28 11:25:36
There is no uninstaller for CUETools. All u have to do is deletes it's folder
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-05-28 13:23:53
Indeed, when you installed it, you just unzipped it to a folder.

If you didn't delete the file user_profiles_enabled, then your settings are in
%appdata%\CUE Tools
%appdata%\CUERipper
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: digitalharmonic on 2015-05-28 14:18:09
korth, well, if it's like this I guess that I refrain from fixing offset and all that stuff I've mentioned before, because judging all of the feedback I wouldn't feel warm and fuzzy enough for doing it  ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-06-03 11:10:29
Not sure if this is a known bug, but CUETools seems to refuse multiple apostrophes. Tried to AR-verify albums with the following directorynames (and corresponding album tags ...)

Belial {1994} ~ '3'
Judas Priest {1990} ~ Painkiller [3'']
Pretty Maids {1999} ~ Shape Edit. 3 'Bandlogo'
Skyclad {1999} ~ Shape Edit. 9 'Vintage Whine'
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-06-09 23:09:26
Not sure if this is a known bug, but CUETools seems to refuse multiple apostrophes. Tried to AR-verify albums with the following directorynames (and corresponding album tags ...)


Nope, the album tags had a quotation mark ".  Which is an illegal filename character yes - but CUETools reacts even when I had not told it to use it in any output filename.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: digitalharmonic on 2015-06-11 19:36:31
Short question: Is there any way to make it visible in the documentation files (log file, accurip file, etc.) with what audio codec version one encoded ? I mean, that would come pretty handy for re-ripping old rips with FLAC 1.1.2, or so...

of course, I've already checked all program options and used a web search engine on that issue, but I couldn't find
anything...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: knubbze on 2015-06-15 19:20:15
I've just started using CueRipper, and have encountered a disc which it seems to be unable to detect the gap information for, yet EAC was able to detect the gaps just fine. Does anybody know why this is happening, and if there is any way to help CueRipper detect the gaps?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: knubbze on 2015-06-16 12:15:21
Also, is there any way to determine if CueRipper is able to detect the gap information prior to ripping a disc (as opposed to having to wait until it's finished ripping the CD and examining the log file)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-06-17 09:55:54
that would come pretty handy for re-ripping old rips with FLAC 1.1.2


which is a nonsensical thing to do, if you really meant to write "re-ripping". FLAC is lossless, remember.

A media player (e.g. foobar2000) can tell which FLAC version a file is, and then you can convert using the tool of your choice (does fb2k transfer embedded album art by now?) - myself I got rid of my 1.1.x files to get rid of a few lines in 'selection properties' windows (less scrolling to get to mp3s ...).
However there seems to be no way - without reencoding - to tell what compression level was used.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: LITBe on 2015-06-23 13:23:20
Hello.
In cuetools i need to add cover art with any name to files tags. Can i do this in batch mode?
I know about "Cover Art Files {string[] array}" settings but i try to add "*.jpg" or ".jpg" and it's not working. Maybe it's not possible to add jpg with any name?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2015-06-27 20:06:26
Feature request:
POSTGAP support
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-02 13:16:01
Hello.
In cuetools i need to add cover art with any name to files tags. Can i do this in batch mode?
I know about "Cover Art Files {string[] array}" settings but i try to add "*.jpg" or ".jpg" and it's not working. Maybe it's not possible to add jpg with any name?

No wildcards. You can match name (cover.jpg), placeholder (%filename%.jpg) or combo (%album% cover.jpg, %artist% - %album%.jpg).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2015-07-22 00:45:33
I'm currently running CUETools on WINE and it somewhat works (did not try CUERipper yet), but it's full of weird side effects. For example mounting /tmp as R:\ then attempting to access R:\ via CUETools results in  "The given path's format is not supported". Going via the internal Z: drive gives something similar: "Z:\tmp - the given path's format is not supported". foobar2000 can access the same folder on WINE just fine.


Regarding this issue, I was able to pinpoint what is causing it: if any of the files in the folder you are trying to browse contain invalid characters by NTFS definition (in my case, ':' in socket file names in /tmp), then CUETools cannot list anything and just spits out that message.
I would be eternally grateful if CUETools could ignore and simply not show invalid filenames instead.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-07-23 11:26:21
There is one thing I haven't understood about track CRC and AccurateRip. I have two different rips of the same CD, one correctly ripped, and the other not:

Correctly ripped:

Code: [Select]
[CUETools log; Date: 23/07/2015 12:03:24; Version: 2.1.5]
[CTDB TOCID: oIvFX8j3CpjAXxoaG80nqUK0sRI-] found.
        [ CTDBID ] Status
        [286d9cba] (5/5) Accurately ripped
Track | CTDB Status
  1   | (5/5) Accurately ripped
  2   | (5/5) Accurately ripped
  3   | (5/5) Accurately ripped
  4   | (5/5) Accurately ripped
  5   | (5/5) Accurately ripped
  6   | (5/5) Accurately ripped
  7   | (5/5) Accurately ripped
  8   | (5/5) Accurately ripped
  9   | (5/5) Accurately ripped
10   | (5/5) Accurately ripped
11   | (5/5) Accurately ripped
12   | (5/5) Accurately ripped
[AccurateRip ID: 000ff65b-00955d8f-ad08480c] found.
Track   [  CRC   |   V2   ] Status
01     [4f456a67|3e590718] (09+03/12) Accurately ripped
02     [f079bd04|bb12e9e8] (09+03/12) Accurately ripped
03     [72d0cc94|1125ef9a] (09+03/12) Accurately ripped
04     [1e85ebc6|7a5e12d2] (09+03/12) Accurately ripped
05     [05eaecaf|4f5c6b35] (09+03/12) Accurately ripped
06     [c5a58f8c|10c53a0d] (09+03/12) Accurately ripped
07     [334a8e1f|7efe2f01] (09+03/12) Accurately ripped
08     [b07a89df|4ccede9b] (09+03/12) Accurately ripped
09     [f48a8a88|01c65c41] (09+03/12) Accurately ripped
10     [dd520537|d0a55829] (09+03/12) Accurately ripped
11     [723d9e81|e9830e6a] (09+03/12) Accurately ripped
12     [8b21c427|658f465f] (09+03/12) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   96,2 [07D56C06] [D236334F]          
01   96,2 [22FA457E] [E8BD2508]   CRC32  
02   90,7 [C6564A4E] [E12258B1]   CRC32  
03   67,7 [87F2D289] [DF1176FA]   CRC32  
04   87,2 [D21518EC] [0E7CC3BC]   CRC32  
05   91,8 [5E97A1D2] [9BF975D0]   CRC32  
06   90,8 [9E4ABAC0] [061F95E8]   CRC32  
07   81,3 [2178157E] [B5E4E176]   CRC32  
08   94,7 [D9139206] [C7C4CB66]   CRC32  
09   82,9 [08C2AFC6] [E05B2F45]   CRC32  
10   61,3 [7C672F27] [AD4A17BB]   CRC32  
11   90,6 [EC97E162] [B3BCEBF9]   CRC32  
12   95,7 [21390958] [096678BB]   CRC32


Not correctly ripped (+690 offset applied):

Code: [Select]
[CUETools log; Date: 23/07/2015 12:08:55; Version: 2.1.5]
Offset applied: 690
[CTDB TOCID: oIvFX8j3CpjAXxoaG80nqUK0sRI-] found.
        [ CTDBID ] Status
        [286d9cba] (5/5) Differs in 1175 samples @06:51:41-06:51:42
Track | CTDB Status
  1   | (5/5) Accurately ripped
  2   | (5/5) Accurately ripped
  3   | (5/5) Differs in 1175 samples @01:11:19-01:11:20
  4   | (5/5) Accurately ripped
  5   | (5/5) Accurately ripped
  6   | (5/5) Accurately ripped
  7   | (5/5) Accurately ripped
  8   | (5/5) Accurately ripped
  9   | (5/5) Accurately ripped
10   | (5/5) Accurately ripped
11   | (5/5) Accurately ripped
12   | (5/5) Accurately ripped
[AccurateRip ID: 000ff65b-00955d8f-ad08480c] found.
Track   [  CRC   |   V2   ] Status
01     [4f456a67|3e590718] (09+03/12) Accurately ripped
02     [f079bd04|bb12e9e8] (09+03/12) Accurately ripped
03     [9147d31b|3442a2e7] (00+00/12) No match
04     [1e85ebc6|7a5e12d2] (09+03/12) Accurately ripped
05     [05eaecaf|4f5c6b35] (09+03/12) Accurately ripped
06     [c5a58f8c|10c53a0d] (09+03/12) Accurately ripped
07     [334a8e1f|7efe2f01] (09+03/12) Accurately ripped
08     [b07a89df|4ccede9b] (09+03/12) Accurately ripped
09     [f48a8a88|01c65c41] (09+03/12) Accurately ripped
10     [dd520537|d0a55829] (09+03/12) Accurately ripped
11     [723d9e81|e9830e6a] (09+03/12) Accurately ripped
12     [8b21c427|658f465f] (09+03/12) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--   96,2 [0306A90C] [DE3DF86A]          
01   96,2 [22FA457E] [E8BD2508] [2938E6DF]
02   90,7 [C6564A4E] [E12258B1]  W/O NULL
03   67,7 [B64DBD16] [B2D0F2EE] [DF1176FA]
04   87,2 [D21518EC] [0E7CC3BC]  W/O NULL
05   91,8 [5E97A1D2] [9BF975D0]  W/O NULL
06   90,8 [9E4ABAC0] [061F95E8]  W/O NULL
07   81,3 [2178157E] [B5E4E176]  W/O NULL
08   94,7 [D9139206] [C7C4CB66]  W/O NULL
09   82,9 [08C2AFC6] [E05B2F45]  W/O NULL
10   61,3 [7C672F27] [AD4A17BB]  W/O NULL
11   90,6 [EC97E162] [B3BCEBF9]  W/O NULL
12   95,7 [C2B0B206] [20BC2A99]  W/O NULL


Don't worry about track 03, please notice the last track (nr. 12) CRCs, instead:

Correct:  12  95,7 [21390958] [096678BB]  CRC32 
Not corect:  12  95,7 [C2B0B206] [20BC2A99]  W/O NULL

As you can see, the last track CRCs are different, while the other CRCs are the same (supposing track 03 was ripped correctly). Example:

Correct: 11   90,6 [EC97E162] [B3BCEBF9]   CRC32
Not correct: 11   90,6 [EC97E162] [B3BCEBF9]  W/O NULL

However, AccurateRip CRCs are the same for track 12:

Correct: 12    [8b21c427|658f465f] (09+03/12) Accurately ripped
Not correct: 12     [8b21c427|658f465f] (09+03/12) Accurately ripped

My question are:
1) Why does this happen? Or, why last track of different rips may have different CRC, but AccurateRip value is the same?
2) Why, in some other rips with different read offset, every track have the same CRC, including the last one, instead?
3) Why sometimes the only track with a different CRC, but again with identical AccurateRip value, is the first one of the album, and not the last one? It seems to depend on the applied offset anyway, with different results if it is positive or negative (positive offset = different CRC only last track, negative offset = different CRC only first track).

I hope my questions are clear.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-23 13:18:15
My question are:
1) Why does this happen? Or, why last track of different rips may have different CRC, but AccurateRip value is the same?
2) Why, in some other rips with different read offset, every track have the same CRC, including the last one, instead?
3) Why sometimes the only track with a different CRC, but again with identical AccurateRip value, is the first one of the album, and not the last one? It seems to depend on the applied offset anyway, with different results if it is positive or negative (positive offset = different CRC only last track, negative offset = different CRC only first track).

See the Knowledgebase article on AccurateRip, Checksum calculation (http://wiki.hydrogenaud.io/index.php?title=AccurateRip#Checksum_calculation) section. Calculation of the AccurateRip Checksum ignores almost 3000 samples from the beginning of the first track and the end of the last track to allow for offset correction.

You don't have to have null samples (zeroes) to have silence. Some albums have inaudible noise (samples with a CRC value but you cannot hear anything) at the beginning of the first track, between tracks, and/or the end of the last track. Other albums may pad these areas with null samples (zeroes).
For 2) the CRC wouldn't change (due to padding of zeroes by the ripping software) when using a different read offset if the samples in that area of the last track were already zeroes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: quangngaicity on 2015-07-24 08:35:05

Follow me. I have decided to check up some rips by which did itself by Exact Audio Copy from firm disks. I converting my rips by foobar2000 into flac image with embedded cuesheet. Any has coincided on base accuraterip though broad gulls EAC suggest otherwise. After careful searches I have detected such thing.
It appears at converting with parametre "convert to album images with cuesheets or chapters", foobar removes pregaps from cue of an image and the copy of the compressed image turns out not ideal. Somehow it is possible to solve this problem?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-07-24 11:09:14
I have not yet got to do this:
I have a few thousand CD rips which I know were upon time of ripping verified Accurate (by dBpoweramp) with - except possibly a handful - no duplicate submissions. I'd like to run CUETools just to help populate the CTDB database. What settings should I use to be sure I do this correctly on first try?

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-24 15:33:15
The CUETools app will only submit to CTDB when using Verify if the CD does not exist in the database and there are two or more AccurateRip matches.
The setting is Settings>Advanced tab>CTDB>Submit to CTDB=True
To properly identify some rips for the correct AccurateRip ID (rips that had a Track 1 pregap and/or a data track), CUETools can use the CUE file, CUERipper or EAC log file, or specific tags in the audio file. I could list scenarios but perhaps you could give more info about your rips so I could narrow it down.
For example: CUETools can't read the dBpoweramp log file but can read the AccurateRip tags in the audio file (if they exist) to identify the CD.

Not sure if this is a known bug, but CUETools seems to refuse multiple apostrophes. Tried to AR-verify albums with the following directorynames (and corresponding album tags ...)


Nope, the album tags had a quotation mark ".  Which is an illegal filename character yes - but CUETools reacts even when I had not told it to use it in any output filename.

If you have Settings>AccurateRip tab>Verify>Write AccurateRip log checked and Settings>AccurateRip tab>Verify>In source folder checked, CUETools will save the log to the source folder.
If you have Settings>AccurateRip tab>Verify>Write AccurateRip log checked and Settings>AccurateRip tab>Verify>In source folder unchecked, CUETools will try to save the log to the Output path (creating folders as needed).
The default name for the log is %filename%.accurip where %filename% is the base name of the file used in Input.

Edit: added more info on the log file
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-24 15:45:47
Follow me...It appears at converting with parametre "convert to album images with cuesheets or chapters", foobar removes pregaps from cue of an image and the copy of the compressed image turns out not ideal. Somehow it is possible to solve this problem?

I'm having trouble following this translation. I think you are referring to a PREGAP command in the original cuesheet. Do you have the original CUE files? If so, could you post the text from one of them (in a CODEBOX please)?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-07-24 21:13:30
To properly identify some rips for the correct AccurateRip ID (rips that had a Track 1 pregap and/or a data track), CUETools can use the CUE file, CUERipper or EAC log file, or specific tags in the audio file. I could list scenarios but perhaps you could give more info about your rips so I could narrow it down.
For example: CUETools can't read the dBpoweramp log file but can read the AccurateRip tags in the audio file (if they exist) to identify the CD.


* They are ripped as one folder per physical disc, one file per track without cuesheets using dBpoweramp, and they have dBp's ACCURATERIPDISCID tag, e.g. 012-000ff634-00948be5-a408630c-11. 
Earlier IIRC, CUETools could not read those, but I can easily auto-populate them with the ACCURATERIPID tag (in this case 000ff634-00948be5-a408630c - is upper case necessary?)

* Exception: those with track 1 pregap (HTOA). dBpoweramp stores those - provided they are long enough, I presume - as a separate file with track number 0.
As far as I can tell, CUETools fails to handle those folders. I got merely 20 of them (well I got more, but those are the ones that were verified accurate when I ripped them).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-24 23:38:35
That's right, it needs to be the ACCURATERIPID tag and lower case in 000ff634-00948be5-a408630c is fine.
If the ID includes track 1 pregap and/or a data track, the message
Using preserved id, actual id is xxxxxxxx-xxxxxxxx-xxxxxxxx
would be added to the accurip log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-07-25 00:54:20
HTOAs as separate file don't work that easy, it seems.

With a track #0 file in the folder:

Code: [Select]
[CUETools log; Date: 25.07.2015 01:42:58; Version: 2.1.6]
Pregap length 00:37:22.
Using preserved id, actual id is 0029f332-020751d1-f0128c10.
[CTDB TOCID: _WOd8IyfdioZDMYr2iT3OcJxIR0-] disk not present in database.
[AccurateRip ID: 00293975-01d790b7-e612670f] disk not present in database.

Renaming it to some other suffix than .flac:

Code: [Select]
[CUETools log; Date: 25.07.2015 01:50:03; Version: 2.1.6]
Pregap length 00:37:22.
[CTDB TOCID: oYHPje9PBhQMkSieHfBw3E0CGbI-] found.
Track | CTDB Status
  1  | (74/76) Accurately ripped
  2  | (73/76) Accurately ripped
  3  | (74/76) Accurately ripped
  4  | (75/76) Accurately ripped
  5  | (75/76) Accurately ripped
  6  | (74/76) Accurately ripped
  7  | (74/76) Accurately ripped
  8  | (74/76) Accurately ripped
  9  | (75/76) Accurately ripped
 10  | (75/76) Accurately ripped
 11  | (75/76) Accurately ripped
 12  | (73/76) Accurately ripped
 13  | (73/76) Accurately ripped
 14  | (74/76) Accurately ripped
 15  | (66/76) Accurately ripped, or (3/76) differs in 119 samples @00:22:66,00:31:04,00:41:40,00:59:05,01:29:38,01:59:33,02:13:19,05:33:48
[AccurateRip ID: 00293975-01d790b7-e612670f] found.
Track  [  CRC  |  V2  ] Status
 01    [71923d00|20419d91] (058+049/389) Accurately ripped
 02    [a58c81c1|b90e8eb0] (059+048/394) Accurately ripped
 03    [b4aa75d7|560a4878] (058+048/390) Accurately ripped
 04    [66216158|d6b055a8] (059+048/391) Accurately ripped
 05    [d887be36|ddba7782] (059+048/390) Accurately ripped
 06    [9717197b|f85a99e7] (059+048/393) Accurately ripped
 07    [99053057|fe1e05c6] (058+047/388) Accurately ripped
 08    [82512738|a7753b4e] (057+048/384) Accurately ripped
 09    [86162db7|ede409bc] (056+048/384) Accurately ripped
 10    [ccbe31ae|3b90b732] (056+047/382) Accurately ripped
 11    [1f18a0f1|88322c44] (057+045/381) Accurately ripped
 12    [bd79b309|0b3a7ac3] (057+046/383) Accurately ripped
 13    [77a7f7bf|f8c574d5] (057+046/387) Accurately ripped
 14    [623e3b7f|fe31b102] (054+045/376) Accurately ripped
 15    [30c6ec37|9a9410f7] (048+041/347) Accurately ripped
Offsetted by -664:
 01    [72bf97b3] (032/389) Accurately ripped
 02    [3fe08e9d] (032/394) Accurately ripped
 03    [bab3d68a] (032/390) Accurately ripped
 04    [4806e82e] (032/391) Accurately ripped
 05    [e813ed20] (032/390) Accurately ripped
 06    [a8f5eb4b] (032/393) Accurately ripped
 07    [5aaef06b] (032/388) Accurately ripped
 08    [97d2ceb4] (031/384) Accurately ripped
 09    [dca3580b] (032/384) Accurately ripped
 10    [9e50dad0] (032/382) Accurately ripped
 11    [a7c0b4ee] (032/381) Accurately ripped
 12    [3334b3d0] (032/383) Accurately ripped
 13    [8c992c06] (032/387) Accurately ripped
 14    [d8080904] (031/376) Accurately ripped
 15    [be7fc3d5] (030/347) Accurately ripped
Offsetted by -10:
 01    [60768463] (010/389) Accurately ripped
 02    [be0b3382] (011/394) Accurately ripped
 03    [a5784fb1] (011/390) Accurately ripped
 04    [937bb04a] (011/391) Accurately ripped
 05    [8bd36e3c] (011/390) Accurately ripped
 06    [d3b00105] (011/393) Accurately ripped
 07    [cc053768] (011/388) Accurately ripped
 08    [1a88b380] (010/384) Accurately ripped
 09    [058fef2b] (010/384) Accurately ripped
 10    [f7cf7881] (010/382) Accurately ripped
 11    [e6b8d175] (010/381) Accurately ripped
 12    [268c8092] (009/383) Accurately ripped
 13    [b6fca936] (010/387) Accurately ripped
 14    [7b178e0b] (010/376) Accurately ripped
 15    [b9655e27] (010/347) Accurately ripped
Offsetted by 1228:
 01    [f8294d33] (027/389) Accurately ripped
 02    [d995907b] (028/394) Accurately ripped
 03    [568ffa2e] (027/390) Accurately ripped
 04    [12819ee9] (028/391) Accurately ripped
 05    [2c3ae906] (027/390) Accurately ripped
 06    [4d31ee39] (028/393) Accurately ripped
 07    [6ed466cb] (028/388) Accurately ripped
 08    [3eef405e] (025/384) Accurately ripped
 09    [014d3490] (025/384) Accurately ripped
 10    [a0486aad] (025/382) Accurately ripped
 11    [0e0ed0af] (025/381) Accurately ripped
 12    [9381e962] (026/383) Accurately ripped
 13    [44ad5c0d] (026/387) Accurately ripped
 14    [5122c4ae] (024/376) Accurately ripped
 15    [f22bab39] (021/347) Accurately ripped
Offsetted by -712:
 01    [25d2a0bd] (002/389) Accurately ripped
 02    [31545d6a] (002/394) Accurately ripped
 03    [56a5b93b] (002/390) Accurately ripped
 04    [fa76c9eb] (002/391) Accurately ripped
 05    [831eee53] (002/390) Accurately ripped
 06    [4a363716] (002/393) Accurately ripped
 07    [fb8d99cc] (002/388) Accurately ripped
 08    [238f2be7] (002/384) Accurately ripped
 09    [f243fc8f] (002/384) Accurately ripped
 10    [db5d29d5] (002/382) Accurately ripped
 11    [cc42ecce] (002/381) Accurately ripped
 12    [c6cb4e2b] (002/383) Accurately ripped
 13    [281a7942] (002/387) Accurately ripped
 14    [13ab3714] (000/376) No match (V2 was not tested)
 15    [3a39274b] (000/347) No match (V2 was not tested)
Offsetted by 1199:
 01    [d25dcd37] (005/389) Accurately ripped
 02    [bd098208] (005/394) Accurately ripped
 03    [f63b7cfb] (005/390) Accurately ripped
 04    [f24c65d9] (005/391) Accurately ripped
 05    [eef9880e] (005/390) Accurately ripped
 06    [3f0883f1] (005/393) Accurately ripped
 07    [9d2befb8] (005/388) Accurately ripped
 08    [f443517c] (005/384) Accurately ripped
 09    [d7aee871] (005/384) Accurately ripped
 10    [6fe61079] (005/382) Accurately ripped
 11    [301082f3] (005/381) Accurately ripped
 12    [7399d6e9] (004/383) Accurately ripped
 13    [42d39081] (005/387) Accurately ripped
 14    [6344686e] (005/376) Accurately ripped
 15    [ea9bd3f1] (000/347) No match (V2 was not tested)
Offsetted by 2461:
 01    [22e944fe] (000/389) No match (V2 was not tested)
 02    [41d0ee1d] (000/394) No match (V2 was not tested)
 03    [a76cddb3] (000/390) No match (V2 was not tested)
 04    [49a9251e] (000/391) No match (V2 was not tested)
 05    [7231bc88] (000/390) No match (V2 was not tested)
 06    [70ddf565] (000/393) No match (V2 was not tested)
 07    [9acfd76d] (000/388) No match (V2 was not tested)
 08    [501d80cf] (000/384) No match (V2 was not tested)
 09    [3cec643e] (000/384) No match (V2 was not tested)
 10    [0b485f3c] (000/382) No match (V2 was not tested)
 11    [993b26df] (000/381) No match (V2 was not tested)
 12    [5bcdac8c] (000/383) No match (V2 was not tested)
 13    [4c3d3326] (000/387) No match (V2 was not tested)
 14    [0774e885] (000/376) No match (V2 was not tested)
 15    [e0bd40c0] (000/347) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  99,9 [A25B8A50] [C210CC14]         
 01  99,9 [6E4301D8] [DFD320FD] [DC642212]
 02  99,9 [7974D1B4] [D1BE642C] [8943426A]
 03  99,9 [DBC0715F] [D8CF503C]         
 04  99,9 [2B7EB1AF] [E507AE5E]         
 05  99,9 [F37A1113] [E94CB895]         
 06  91,2 [E433090A] [C9D483EB]         
 07  99,9 [E9B1F22C] [EF29B7CA]         
 08  99,9 [9A7164F5] [82C3D41B]         
 09  99,9 [308E68B0] [E3E3EF02]         
 10  99,9 [3080BFE8] [45EAA3A7]         
 11  99,9 [250DAA92] [39FE3226]         
 12  99,9 [9768A319] [30B7958B]         
 13  99,9 [E880057E] [37E1882C]         
 14  99,9 [028A6E2D] [F2442134]         
 15  99,9 [561D07BA] [F7E34CF0]         
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-25 05:07:15
actual id = 0029f332-020751d1-f0128c10
hex 10=16 tracks

ACCURATERIPID tag = 00293975-01d790b7-e612670f
hex 0f=15 tracks

I assume the HTOA file has tags so CUETools is grouping it as an additional Track (not hidden). I tested it with a CUETools HTOA file (it has no tags) and it worked correctly.


EDIT: Checked an Easy Audio Copy rip with a tagged HTOA and it reacts the same way as yours (grouping the HTOA file as an additional track).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-07-25 13:57:30
I tested it with a CUETools HTOA file (it has no tags)


Right.  Well, wiping tags is out of the question (wishlist item for CUETools: treat files tagged with track number 0 as HTOA), but I may just temporarily use Bulk Rename Utility to change suffix to .flacHTOAflac and back later, or ignore those twenty.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xtemp09 on 2015-07-27 10:13:17
Is the project dead?

Since:
Quote
16.04.2012: CUETools 2.1.4:

And Sourceforge support page looks like it was abandoned.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-27 14:28:16
You didn't provide links to where you were looking.
This project is currently named CUETools.NET (http://sourceforge.net/projects/cuetoolsnet/?source=directory) on sourceforge.
CUETools wiki (http://www.cuetools.net/wiki/Main_Page).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xtemp09 on 2015-07-27 14:33:11
You didn't provide links to where you were looking. This project is currently named CUETools.NET (http://sourceforge.net/projects/cuetoolsnet/?source=directory) on sourceforge.
CUETools wiki (http://www.cuetools.net/wiki/Main_Page).


CUETools 2.1.4 was released on 16.04.2012.

Thanks for the sourceforge link. If you press "Bugs (http://sourceforge.net/p/cuetoolsnet/bugs/)", you will see too many tickets opened five years ago and nobody answered there.

Can anyone contact the author?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-07-27 14:45:19
changelog (http://www.cuetools.net/wiki/CUETools_Changelog)
The developer reads this topic more often than sourceforge but he doesn't always reply to bug reports or suggestions. He just adds them to his todo list.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2015-07-27 15:39:30
CUETools 2.1.4 was released on 16.04.2012.


The current version is 2.1.5 and there is a development version of 2.1.6. You are reffering to old version!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xtemp09 on 2015-07-27 17:26:49
Alright, I agree that I didn't go deep into it when writing that post. But I'm right that the venerable authors don't pay much attention to feedback.

I thought that the project is obsolete because I saw the page with FLACCL (http://www.cuetools.net/wiki/FLACCL) - the tool I use; that page offers FLACCL v. 0.3.

I'm encountering a problem with FLACCL. It doesn't support 24-bit/192 kHz WAV. The "Bugs" page on Source forge is abandoned. Where do I post bug report?

P.S.
$ CUETools.FLACCL.cmd.exe
FLACCL#0.4, Copyright © 2010 Grigory Chudov.
The latest one downloaded from the site.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-07-27 17:49:06
We have a dedicated flacCL thread http://www.hydrogenaud.io/forums/index.php...4628&st=425 (http://www.hydrogenaud.io/forums/index.php?showtopic=64628&st=425)
I uploaded recent versions until lately http://www.hydrogenaud.io/forums/index.php?showtopic=106446 (http://www.hydrogenaud.io/forums/index.php?showtopic=106446)
For the newest just download latest 2.16 and copy out the needed files. Support up to 192kHz is fixed a while now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xtemp09 on 2015-07-31 17:30:38
When I'm trying to encode 24-bit/WAV with CUETools, I get: "Audio format is not Red Book PCM.."

How to make it work?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: marc2003 on 2015-07-31 18:22:03
it's not supported...

http://cuetools.net/wiki/CUETools#Supported_formats (http://cuetools.net/wiki/CUETools#Supported_formats)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xtemp09 on 2015-07-31 21:16:02
Ok, I have a 24-bit/FLAC (WAV), how do I slice it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-07-31 22:31:41
Ok, I have a 24-bit/FLAC (WAV), how do I slice it?


It's true that only 16-bit 44.1 kHz audio can be burned to audio CD (if you have some other format, it didn't come directly from CD), but there's no reason CUETools couldn't go ahead and convert the files anyway. The fact that it won't is yet another example of software, on principle, refusing to work with cue sheets which are being used for something more than what they were designed for.

For now, for splitting your (most likely pirated) non-CD-sourced audio, I would just use foobar2000. Drag the .cue into the playlist, make sure all the tracks are highlighted, right-click on one, Convert, choose "..." to set up the converter to output separate files in whatever format you want. The interface takes some getting used to, but once you get the hang of it, you'll be using it for everything. The downside is that it won't make a file-per-track/non-compliant cue sheet to go along with the split files, but for real CD rips it's no problem for CUETools to do that later.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: xtemp09 on 2015-08-01 08:16:46
Many thanks for that advice, however, I used AIMP. foobar2000 repels me by its interface. =)

I guess CUETools is no use for something different from audio CD.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2015-08-01 14:21:29
Let's stay on topic, please.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-08-02 01:27:24
*looks at page count and recalls staggering number of topic changes in this thread*
*considers possibility that greynol is joking*

Anyway, perhaps I should be more direct:

CUETools warning the user that the audio is not Red Book is good, but refusing to operate on it seems like an unnecessary restriction. Lifting that restriction is a feature request which I hope Gregory will take into consideration.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-02 10:01:10
CUETools warning the user that the audio is not Red Book is good, but refusing to operate on it seems like an unnecessary restriction. Lifting that restriction is a feature request which I hope Gregory will take into consideration.


Argument pro: HDCD rips decoded to 24 bits. CUETools even supports the decoding, but produces files it then refuses to handle.

(Decoding HDCD upon ripping to lossless is bad, though.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-08-02 14:52:25
I've two suggestions about:

CUETools.exe /verify <cuefilename>   verify an image using AccurateRip database.
ArCueDotNet.exe <cuefilename>   console version of AccurateRip verification.

Please add two options to CUETools.exe (/verify mode):

/offset: specify an offset to be used during the AccurateRip verification.
/verbose: activate verbose mode so that CTDB information are also shown (exactly the same of ArCueDotNet.exe -v).

And one option to ArCueDotNet.exe:

-offset: specify an offset to be used during the AccurateRip verification.

Do you think it would be possible to add them?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-10 08:24:40
HDCDs. CUETools and hdcd.exe seem not to output bit-identical files. Known issue? If so, with which one of them?
I have noticed that both halve the volume, so peaks are the same.

(foo_hdcd agrees with neither,  it seems.)


(Decoding HDCD upon ripping to lossless is bad, though.)


Yeah ... I found a few CDs which I had, ignorantly, ripped with HDCD decoding (dBpoweramp, uses hdcd.exe), and re-ripped them. Then I started to play with decoders ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-08-11 00:00:34
HDCDs. CUETools and hdcd.exe seem not to output bit-identical files. Known issue? If so, with which one of them?
I have noticed that both halve the volume, so peaks are the same.

(foo_hdcd agrees with neither,  it seems.)


(Decoding HDCD upon ripping to lossless is bad, though.)


Yeah ... I found a few CDs which I had, ignorantly, ripped with HDCD decoding (dBpoweramp, uses hdcd.exe), and re-ripped them. Then I started to play with decoders ...

Just tried Knopflers Golden Heart that has a good amount of hdcd peak extension and the music content is 100% identical with using CUEtools against hdcd.exe at cmd.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-11 09:12:59
HDCDs. CUETools and hdcd.exe seem not to output bit-identical files. Known issue? If so, with which one of them?
I have noticed that both halve the volume, so peaks are the same. [...]

Just tried Knopflers Golden Heart that has a good amount of hdcd peak extension and the music content is 100% identical with using CUEtools against hdcd.exe at cmd.


No peak extension on this one, but low-level gain: King Crimson: Larks' Tongue (30th Anniversary editions from y2k)


For laziness reporting only track 2 (which is short)


1) CUETools converted (to 24 bits, stop looking after 750) vs HDCD.exe converted:

Compared 7755720 samples.
Differences found: 4752 values, starting at 0:00.000000, peak: 0.0002804 at 0:00.023583, 1ch
Detected offset as 0 samples.


2) As 1), but not stopped looking: same result.


3) foobar2000 converted using foo_hdcd postprocessing, halve output volume: "Always" (because the other two do) - compared with and w/o "Don't reset DSP" :
Bit-identical.


4) fb2k-converted against hdcd.exe-decoded file:

Compared 7755720 samples.
Differences found: 805810 values, starting at 0:00.033651, peak: 0.0000024 at 2:47.694104, 2ch
Detected offset as 0 samples.


4) fb2k-converted file against CUETools-converted file:

Compared 7755720 samples.
Differences found: 808751 values, starting at 0:00.000000, peak: 0.0002804 at 0:00.023583, 1ch
Detected offset as 0 samples.




Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-11 09:16:19
(I'll pursue this thread for human error before bothering kode54 about foo_hdcd).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-08-11 14:34:28
I don't have this cd but tried Oldfield, Killing Fields and Camel, A Nod And A Wink. Complety image files and no single bit different. Is this Krimson cd accurately ripped? Only an idea but maybe a ripping error creates undefned values?

my hdcd.exe 143.360 Bytes, md5 e17a38e6723ae2a0fadd6c927c878767
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-08-11 18:13:27
Quote from: Abelenki link=msg=0 date=
CUETools don't work under Windows 10

hello,

first of all, thanks for great application.

i use CUETools occasionally for un-merging some image+cue FLAC's into track FLAC's. but recently i switched to Windows 10, and no versions of CUETools work there, even beta (unstable).

prerequisites are met (.NET 2.0 and 3.5 are installed via Windows Features; VC 2005-2013 are installed, including 2008, of course), but CUETools still don't work.

can you please look into Windows 10 compatibility? i miss CUETools badly. 

it just crashes with "CUE Tools has stopped working" message.

If CUETools cannot access one of the plugins or other support files when it starts, that can make it crash. Check the file/folder permissions where you are trying to run CUETools from or try unpacking the full contents of the CUETools_2.1.5.zip to a different location such as C:\ (you'll end up with C:\CUETools_2.1.5\) and running CUETools from there.
CUETools is working fine so far on my Windows 10 Pro system.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-11 23:27:29
I've uploaded a file with some megabytes off this CD, and can share the link and password with those who want to test. Wombat, you got pm in a minute.


Is this Krimson cd accurately ripped? Only an idea but maybe a ripping error creates undefned values?

Could have been a point, but it was verified as Accurate upon ripping.

Funny CUETools log though - but even if there were issues with the last two tracks, it was track #2 I did the more extensive testing on.

Code: [Select]
[CUETools log; Date: 12.08.2015 00:07:09; Version: 2.1.6]
HDCD: peak extend: none, transient filter: none, gain: -4,0dB..0,0dB
[CTDB TOCID: OcB1KSGANlnyXItjuYwf6tst64k-] found.
Track | CTDB Status
  1  | (175/203) Accurately ripped
  2  | (179/203) Accurately ripped
  3  | (179/203) Accurately ripped
  4  | (179/203) Accurately ripped
  5  | (174/203) Accurately ripped
  6  | (  5/203) Accurately ripped, or (169/203) differs in 6711 samples @00:00:02-00:00:08,06:37:21,06:37:74,06:38:16,06:38:34,06:40:42,06:41:02,06:41:20
[AccurateRip ID: 000bd8ff-003da00e-560aed06] found.
Track  [  CRC  |  V2  ] Status
 01    [9343727c|a1b9c3e0] (008+005/486) Accurately ripped
 02    [6d99968e|8642cbfb] (008+005/492) Accurately ripped
 03    [9080d78e|2465d650] (008+005/489) Accurately ripped
 04    [0606b398|95d6cd24] (008+005/493) Accurately ripped
 05    [d15f2c09|23e6644d] (008+005/491) Accurately ripped
 06    [13a1a829|8ad124a0] (008+005/480) Accurately ripped
Offsetted by 744:
 01    [8de29f83] (003/486) Accurately ripped
 02    [db698deb] (003/492) Accurately ripped
 03    [640108d0] (003/489) Accurately ripped
 04    [87b0947b] (003/493) Accurately ripped
 05    [54739ad2] (003/491) Accurately ripped
 06    [0d0672ba] (003/480) Accurately ripped
Offsetted by 1472:
 01    [a19fdd43] (000/486) No match (V2 was not tested)
 02    [6cf35d72] (000/492) No match (V2 was not tested)
 03    [58723100] (000/489) No match (V2 was not tested)
 04    [f53201e2] (000/493) No match (V2 was not tested)
 05    [09c5921c] (000/491) No match (V2 was not tested)
 06    [faa4398d] (000/480) No match (V2 was not tested)
Offsetted by 1488:
 01    [820c7cdf] (003/486) Accurately ripped
 02    [50298290] (003/492) Accurately ripped
 03    [bcfedf17] (003/489) Accurately ripped
 04    [4a581808] (003/493) Accurately ripped
 05    [3ddacb42] (000/491) No match (V2 was not tested)
 06    [c5dd3f33] (000/480) No match (V2 was not tested)
Offsetted by 2071:
 01    [1d1a1196] (046/486) Accurately ripped
 02    [2f111ed0] (046/492) Accurately ripped
 03    [518aa9c1] (047/489) Accurately ripped
 04    [0562979e] (047/493) Accurately ripped
 05    [e4d30a91] (000/491) No match (V2 was not tested)
 06    [61298651] (000/480) No match (V2 was not tested)
Offsetted by 2085:
 01    [0df27c7c] (016/486) Accurately ripped
 02    [d3688d0b] (016/492) Accurately ripped
 03    [d3ccc1ba] (015/489) Accurately ripped
 04    [57931379] (016/493) Accurately ripped
 05    [bc755f47] (000/491) No match (V2 was not tested)
 06    [ecd11f85] (000/480) No match (V2 was not tested)
Offsetted by 2139:
 01    [661e87d9] (016/486) Accurately ripped
 02    [4811206d] (016/492) Accurately ripped
 03    [22386e59] (016/489) Accurately ripped
 04    [b40de01a] (016/493) Accurately ripped
 05    [b7adb2bb] (000/491) No match (V2 was not tested)
 06    [3d0dfae8] (000/480) No match (V2 was not tested)
Offsetted by 2157:
 01    [793c751b] (122/486) Accurately ripped
 02    [fe30e051] (127/492) Accurately ripped
 03    [5523646a] (125/489) Accurately ripped
 04    [4da32041] (127/493) Accurately ripped
 05    [5d6d82f6] (000/491) No match (V2 was not tested)
 06    [25fe02fa] (000/480) No match (V2 was not tested)
Offsetted by 2163:
 01    [140ca029] (002/486) Accurately ripped
 02    [02bccdbd] (002/492) Accurately ripped
 03    [4a98a984] (002/489) Accurately ripped
 04    [b67d6082] (002/493) Accurately ripped
 05    [4f5f9ec8] (000/491) No match (V2 was not tested)
 06    [436d6caf] (000/480) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL]
 --  90,1 [76EB613F] [3077AA68]         
 01  90,1 [CA8F86BC] [0FB89500]         
 02  54,6 [A7EBAB43] [69475155]         
 03  65,8 [47D5973F] [5C3E5A4F]         
 04  90,1 [45C56739] [E076D49D]         
 05  90,1 [B713769F] [1511EC8F]         
 06  90,1 [504B09B6] [1B6F261A]         

Curious as I am, I tried a repair. The pressings are patently different, as I lose Accurate-ness with offsets 0 and 744, but achieve an AccurateRip match at six other offsets.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-08-12 01:01:04
Ok, lets make it simple. The files decoded with CUEtools and my hdcd.exe are identical again.
I found the cjk folder online and tried an older version.
The hdcd i use is the newest from 14.11.2008 simply called hdcd.zip
Using an old verions from 2007 indeed creates a different file.
Near the end of the song we have some seconds constant noise down ~100db difference.
Using the hdcd-0.2-x64 from the same place has the same content as the older versions and so is different to my used non 0.2 with the same newer date.
Since this very silent noise hardly can be called creating different files we have to ask the developer how this comes.
Sine Grigory most likely had some more or less official code for his dll i guess this one is right.
No idea atm how to bring this further and how to contact the dev.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-12 08:16:43
Ok, lets make it simple. The files decoded with CUEtools and my hdcd.exe are identical again.
I found the cjk folder online and tried an older version.
The hdcd i use is the newest from 14.11.2008 simply called hdcd.zip
Using an old verions from 2007 indeed creates a different file.


The one you use to get bit-identical results, is the one in the zip file, that when unpacked has an md5sum of e17a38e6723ae2a0fadd6c927c878767 ?
That is precisely the one I used to get different results.

So ... WTF? I use CUETools 2.1.6. Everything on 64-bit Windows 7. (Intel Core2 CPU.)

But that November 2008 date is interesting, because my original rip log says October 2008. And the file generated back then, using whatever version followed dBpoweramp version 13, is bit-identical to the one I create today using the November 2008 version.






Near the end of the song we have some seconds constant noise down ~100db difference.


Of course - it has to be the low-level gain implementation that makes the difference, because there is no peak extension in the file.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-08-12 14:08:03
The one you use to get bit-identical results, is the one in the zip file, that when unpacked has an md5sum of e17a38e6723ae2a0fadd6c927c878767 ?

Yup, w10pro x64 here. Did you notice the included CUEtools hdcd.dll is from 13.08.2008? At the cjk download location are dlls in hdcd-0.2-dev.zip that are one day newer. I am a bit to lazy to test these with CUEtools atm but could be interesting.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-12 19:05:18
Did you notice the included CUEtools hdcd.dll is from 13.08.2008? At the cjk download location are dlls in hdcd-0.2-dev.zip that are one day newer. I am a bit to lazy to test these with CUEtools atm but could be interesting.


I did not know, but if I replace CUETools' hdcd.dll file with the cjk file from hdcd-0.2-dev.zip or hdcd-dev-0.2.zip, I still get different results.

How do I write a .bat file that calls a dll?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-08-12 19:24:27
How do I write a .bat file that calls a dll?

No idea, you may use another GUI like eac3to?
I think all we do is fishing in the dark. I don't know who to ask for these differences or how to contact the dev.
One thing for you to be certain may be to capture the output of the Krimson track decoded with WMP to know what way of decoding on your system is the right one.
There must be a howto around for that.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-12 23:27:33
OK, now I have chosen to bother kode54 for foo_hdcd as well.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-08-12 23:31:29
OK, now I have chosen to bother kode54 for foo_hdcd as well.

Thats the spirit!
Nonetheless these decoders to my understanding must create identical files to WMP output.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-16 19:12:05
OK, now I have differences between FLAC and WavPack output ... or maybe I have to reboot between replacing .dll files?!? I need to reset results and try over, but not today.

OK, now I have chosen to bother kode54 for foo_hdcd as well.

Thats the spirit!


Yeah, I cannot repair, but I am darn good at criticizing those who actually do something



Nonetheless these decoders to my understanding must create identical files to WMP output.


But that does not convert, does it?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2015-08-16 19:40:20
But that does not convert, does it?

All hdcd decoders offered are simply based on mimic the WMP output.
Here someone checks it. http://lukeskaff.com/?p=17 (http://lukeskaff.com/?p=17)
Do the same and you will know what solution of yours is right.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-16 21:39:43
But that does not convert, does it?

All hdcd decoders offered are simply based on mimic the WMP output.
Here someone checks it. http://lukeskaff.com/?p=17 (http://lukeskaff.com/?p=17)
Do the same and you will know what solution of yours is right.


Right. Googling a bit, I found the discussion between the two of you back then.

Well that WMP plugin works only on XP. Which I have, a fragile thing I do not want WMP on. It will have to wait until I get a virtual machine up and going.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-08-18 06:32:01
Sonata in d'oh minor coming up. The differences are due to applying HDCD track-based or image-based.
I store as tracks. If I use fb2k (w/o HDCD processing) to generate wav+cue, and process the .wav using hdcd.exe, I get the very same results as if I use CUETools.
Presumably, the CUETools output is even more correct than the per-track based HDCD.exe, because a DAC that is fed an S/PDIF stream does not see track boundaries.
(Last time I got a major difference in one track, I cannot explain that; maybe it was after fiddling around with .dlls, maybe I dumped the files into fb2k before completely done causing a read/write conflict ... I think I will write that off without worrying.)


foo_hdcd is not bit-exactly the same as hdcd.exe. Official build:
Differences found: 21246657 values, starting at 0:00.104626, peak: 0.0000091 at 46:21.342222, 1ch
(A new version kode54 built for the discussion, brings it down to ...73.)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-09-04 13:21:30
Just curious: when CUETools reports "CTDB: verified OK, confidence 10, or verified OK, confidence 3" - what is then the difference between those in the 10-group and those in the 3-group? Offset, like AccurateRip?
The log only says 13/15 (for the lowest track).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-09-04 14:03:49
Different TOC due to Data track or disc pregap (HTOA) but stored under the same TOCID (the TOCID is calculated using audio Tracks only).

A pressing with a Data track is stored separately under a different CTDBID than one without (even when the Tracks have the same CRCs). Same for a pressing with a disc pregap (HTOA) or if the length of a Data track or disc pregap (HTOA) is different.

Edit: You can see the CTDBID in the accurip log by enabling the Detailed log (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB).
Edit2: Changed phrasing because bad rips also have a different CTDBID but matching tracks are grouped together in the log.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-09-04 14:57:34
Edit: You can see the CTDBID in the accurip log by enabling the Detailed log (http://www.cuetools.net/wiki/CUETools_Advanced_Settings:_Advanced#CTDB).

Yay! Now I realize that I do not get the most verbose log by merely ticking "Verbose" under the AccurateRip tab ...


Edit2: Changed phrasing because bad rips also have a different CTDBID.

OK, so for some CD the detailed log shows three different CTDBIDs;
- one is a different rip with presumably an error, so it gets a different checksum and thus a different CTDBID;
- one verifies mine, and has a data track like mine has;
- and then one with a higher confidence, but no data track.


That gets me curious again; which of the following would/could be the case?
(1) There is a different pressing which has the same audio bits and hence the same audio checksum, but no data session, hence a different TOC and hence a different CTDBID - but CUETools knows from either (a) the audio checksum or (b) the tracklengths that it should be compared to mine?
(2) The other submissions could very well be from the same pressing, but the information concerning the data track is not preserved in a way accessible to CUETools, so it treats it as if it were case (1)?
(3) None of the above?
I verify by ACCURATERIPID extracted from dBpoweramp tags, so even without cuesheets I assume CUETools knows quite a lot from me. 


I have only one rip with both HTOA AND data track, and then all CDTB entries (and all AR entries) perfectly agree.  Anyway, still a bit annoyed that CUETools cannot guess that a track 00 in a folder is a HTOA ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-09-04 15:59:01
The TOCID is a calculated TOC (Table of Contents) of the audio tracks only with the 1st track starting at zero (Data track and disc pregap (HTOA) info are excluded in this calculation but are stored separately). Each related CTDBID is stored under a TOCID.

The TOCID would be calculated from your rip and searched, then if found the CRC32 of your rip (except for some leadin and leadout samples) would be checked against any existing CTDBID (using an offset-finding checksum that will detect any offset difference between the rip in the database and your rip, even if your rip contains some errors).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lazlo Nibble on 2015-09-05 22:49:22
Is there any way to get CUERipper to run a user-definable external process after it finishes a rip?  I've automated a bunch of post-rip workflow, formerly with EAC+REACT, now with my own scripting configured as an EAC "external compressor". Now I'd like to move everything to CUERipper so I can get rid of certain steps I have to do myself if I use EAC, and because it writes UTF-8 cuesheets.  But I can't see any way to have it actually trigger my external processing once it's done with the rip.

The console ripper doesn't really work for me; I want to be able to tune all the metadata before I kick off the rip, not clean it up afterwards.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-09-06 15:26:32
Not that I know of.

Note: CUERipper only passes the audio to the encoder. Tags are added after all the encoded files are written using taglib-sharp (https://github.com/mono/taglib-sharp/) (for most formats).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-09-10 16:04:14
What are the possible error messages CUETools can return upon trying to verify corrupt files? I know two: "unsupported subframe coding" and "frame crc mismatch".  (Also of course "Audio format is not Red Book PCM", but I have not seen that arise from corruption.)

I just put a few thousand through it (89 uploads, that's my meager contribution of the week) and I cannot manually read through every line.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2015-09-10 16:13:41
In theory, there's a lot. Not sure how probable some of them are.

Code: [Select]
[ec2-user@ip-10-226-89-162 cuetoolsnet-code]$ fgrep "new Exception" CUETools.Codecs.FLAKE/FlakeReader.cs
...
throw new Exception("invalid frame");
throw new Exception("unsupported bps coding");
throw new Exception("unsupported frame coding");
throw new Exception("invalid sample rate mode");
throw new Exception("invalid channel mode");
throw new Exception("header crc mismatch");
throw new Exception("unsupported residual coding");
throw new Exception("invalid partition order");
throw new Exception("cbits >= 16");
throw new Exception("negative shift");
throw new Exception("unsupported subframe coding (ch == x)");
throw new Exception("invalid subframe type");
throw new Exception("frame crc mismatch");
throw new Exception("FLAC stream not found");
throw new Exception("headerless file unsupported");
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-09-10 19:39:08
Thanks. "unsupported" is evidently not what metalheads want to use in a song title, so these were pretty quickly checked ;-)

Feature suggestion: CUETools could report e.g. "###DECODING ERROR### -" in front of the message.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dadadacicici on 2015-09-23 17:06:43
Hi there, I have been trying to use CueTools for a while but at times the results are not as they should supposed to be.

For example if I am ripping a double cd I just end up with disc 2 only because the program will just overwrite disc 1 even if it did state disc 1 and 2 when retrieving the titles via the database.
I have to remember every time to modify the name of disc 1 and there seems not to be any option to fix that.

At times I might get different AccurateRip results like that:

Quote
CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov

Joel Xavier & Andy Lekker / Whoop! Records

Used drive  : HL-DT-ST DVD-RAM GH22NP20  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 102
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo

    Peak level 98.8 %
    Range quality 100.0 %
    Copy CRC EE4CE234
    Copy OK

No errors occurred

AccurateRip summary

Track  1  accurately ripped (confidence 3)  [D7E7D661]
Track  2  accurately ripped (confidence 3)  [B7BE380B]
Track  3  accurately ripped (confidence 3)  [E06C08AC]
Track  4  accurately ripped (confidence 3)  [DDBB47DD]
Track  5  accurately ripped (confidence 3)  [3A0B3CD1]
Track  6  accurately ripped (confidence 3)  [37851E71]
Track  7  accurately ripped (confidence 3)  [5E502743]
Track  8  accurately ripped (confidence 3)  [EE66FB22]
Track  9  cannot be verified as accurate (confidence 3)  [589E7CB8], AccurateRip returned [4B6FBBC2]



Quote
Exact Audio Copy V1.0 beta 6 from 9. April 2015

Various / Andy Lekker & Joel Xavier - Whoop! Records

Used drive  : HL-DT-STDVD-RAM GH22NP20  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : No

Read offset correction                      : 102
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


Range status and errors

Selected range

    Peak level 98.8 %
    Extraction speed 4.1 X
    Range quality 100.0 %
    Copy CRC EE4CE234
    Copy OK

No errors occurred

AccurateRip summary

Track  1  accurately ripped (confidence 3)  [7A743493]  (AR v2)
Track  2  accurately ripped (confidence 3)  [42FE6D49]  (AR v2)
Track  3  accurately ripped (confidence 3)  [1D1C4DA1]  (AR v2)
Track  4  accurately ripped (confidence 3)  [12A6A005]  (AR v2)
Track  5  accurately ripped (confidence 3)  [1FC98BC3]  (AR v2)
Track  6  accurately ripped (confidence 3)  [6795CB85]  (AR v2)
Track  7  accurately ripped (confidence 3)  [06DAE983]  (AR v2)
Track  8  accurately ripped (confidence 3)  [A4EC8B1D]  (AR v2)
Track  9  cannot be verified as accurate (confidence 1)  [57EE6EBA], AccurateRip returned [4B6FBBC2]  (AR v2)

8 track(s) accurately ripped
1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

End of status report

---- CUETools DB Plugin V2.1.6

[CTDB TOCID: 7iyjmsPsuL9DStBu_cJgCjiM01Y-] found


Same cd... different values. How can it be?

The last track is giving me headaches since every copy I tracked down does have issues on the very last minutes though it does sound fine with the EAC [57EE6EBA] value being confirmed by other 8 different rips also using different softwares.

Also when I try to rip any cd with a data track the program freezes and I am back to EAC to do the job.

On top of that today I came across another issue. Vangelis - Opera Sauvage (which I know it should have pre-emphasis) does not show on CueRipper 2.1.5 while it does show with EAC 0.99pb5.

Quote
REM GENRE Electronic
REM DATE 1979
REM DISCID 650A1907
REM COMMENT "ExactAudioCopy v0.99pb5"
CATALOG 0042282966322
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
FILE "Vangelis - Opera Sauvage.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Hymne"
    PERFORMER "Vangelis"
    ISRC FRF067900070
    FLAGS PRE
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    TITLE "Rêve"
    PERFORMER "Vangelis"
    ISRC FRF067900080
    FLAGS PRE
    INDEX 00 02:42:02
    INDEX 01 02:46:35


Quote
REM DISCID 650A1907
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
CATALOG 0042282966322
REM DATE 1979
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov"
FILE "Vangelis - Opera Sauvage.wav" WAVE
  TRACK 01 AUDIO
    PERFORMER "Vangelis"
    TITLE "Hymne"
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    PERFORMER "Vangelis"
    TITLE "Rêve"
    INDEX 01 02:46:35


I seem to recollect from another thread (https://www.hydrogenaud.io/forums/index.php?showtopic=103716&view=findpost&p=870847) that the weird indexes 00 on the EAC cuesheet are a result of EAC getting confused or something and are wrong.

So I guess I will just add the FLAG PRE to the CueRipper rip though I had to do the job twice to get a more accurate result using the best of both worlds.

I like the ease of use of CueRipper. It is generally faster in getting the same results of EAC, but when it comes to the aforementioned issues and with scratched cd's I need to go back to the slower error recovery routines of EAC.

I hope this will be fixed in the next builds.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-09-23 19:18:00
Quote
For example if I am ripping a double cd I just end up with disc 2 only because the program will just overwrite disc 1 even if it did state disc 1 and 2 when retrieving the titles via the database.
I have to remember every time to modify the name of disc 1 and there seems not to be any option to fix that.

You can change the Output Path Template (http://www.cuetools.net/wiki/CUERipper_Settings#.2810.29_Output_path_.7Bdrop-down_list.7D). Adding [%unique%] before the .cue will prevent overwriting. Adding something like  $ifgreater($max(%discnumber%,%totaldiscs%),1, '('CD%discnumber% of %totaldiscs%')',) before the .cue will add " (CD1 of 2)" (without the quotes) when TotalDiscs > 1.
[ '('CD%discnumberandname%')'] should give a similar result.
 
Quote
At times I might get different AccurateRip results...Same cd... different values. How can it be?

What does the *.accurip file show?

Quote
Also when I try to rip any cd with a data track the program freezes

There was a problem with 2.1.4 related to the 'Detailed log (http://www.cuetools.net/wiki/CUERipper_Options)' setting but you shouldn't still have a problem in 2.1.5.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dadadacicici on 2015-09-24 21:45:14
Same drive same cd

CueRipper
Quote
Track 1 accurately ripped (confidence 3) [D7E7D661]
Track 2 accurately ripped (confidence 3) [B7BE380B]
Track 3 accurately ripped (confidence 3) [E06C08AC]
Track 4 accurately ripped (confidence 3) [DDBB47DD]
Track 5 accurately ripped (confidence 3) [3A0B3CD1]
Track 6 accurately ripped (confidence 3) [37851E71]
Track 7 accurately ripped (confidence 3) [5E502743]
Track 8 accurately ripped (confidence 3) [EE66FB22]
Track 9 cannot be verified as accurate (confidence 3) [589E7CB8], AccurateRip returned [4B6FBBC2]


EAC
Quote
Track 1 accurately ripped (confidence 3) [7A743493] (AR v2)
Track 2 accurately ripped (confidence 3) [42FE6D49] (AR v2)
Track 3 accurately ripped (confidence 3) [1D1C4DA1] (AR v2)
Track 4 accurately ripped (confidence 3) [12A6A005] (AR v2)
Track 5 accurately ripped (confidence 3) [1FC98BC3] (AR v2)
Track 6 accurately ripped (confidence 3) [6795CB85] (AR v2)
Track 7 accurately ripped (confidence 3) [06DAE983] (AR v2)
Track 8 accurately ripped (confidence 3) [A4EC8B1D] (AR v2)
Track 9 cannot be verified as accurate (confidence 1) [57EE6EBA], AccurateRip returned [4B6FBBC2] (AR v2)


Accurip

Quote
[CUETools log; Date: 24/09/2015 19.47.56; Version: 2.1.5]
[CTDB TOCID: 7iyjmsPsuL9DStBu_cJgCjiM01Y-] found.
Track | CTDB Status
  1  | (6/6) Accurately ripped
  2  | (6/6) Accurately ripped
  3  | (6/6) Accurately ripped
  4  | (6/6) Accurately ripped
  5  | (6/6) Accurately ripped
  6  | (6/6) Accurately ripped
  7  | (6/6) Accurately ripped
  8  | (6/6) Accurately ripped
  9  | (5/6) Accurately ripped
[AccurateRip ID: 0014cc8b-00989ece-750e8409] found.
Track  [  CRC  |  V2  ] Status
01    [d7e7d661|7a743493] (0+3/3) Accurately ripped
02    [b7be380b|42fe6d49] (0+3/3) Accurately ripped
03    [e06c08ac|1d1c4da1] (0+3/3) Accurately ripped
04    [ddbb47dd|12a6a005] (0+3/3) Accurately ripped
05    [3a0b3cd1|1fc98bc3] (0+3/3) Accurately ripped
06    [37851e71|6795cb85] (0+3/3) Accurately ripped
07    [5e502743|06dae983] (0+3/3) Accurately ripped
08    [ee66fb22|a4ec8b1d] (0+3/3) Accurately ripped
09    [589e7cb8|57ee6eba] (0+0/3) No match

Track Peak [ CRC32  ] [W/O NULL]
--  98,8 [EE4CE234] [CEE895AF]         
01  98,8 [A221583D] [9992DF6D]         
02  98,8 [5CC78955] [84F97CB5]         
03  98,8 [8965A6C9] [25D4BD73]         
04  98,8 [EE8D99AE] [7073213C]         
05  98,8 [006A4937] [47C9342E]         
06  98,8 [B0FB5684] [904B1008]         
07  98,8 [A5E4F7AB] [214EB42F]         
08  98,8 [BCB386BD] [45269E9F]         
09  98,8 [D2C4DF7F] [1108173C]


If I am comparing the resulting wav files in WaveLab they are identical.
Not on all cd's I am getting the different values though the waveform content is exactly the same. Most of the times the values for both EAC and CueRipper are the same.
I take EAC and CueRipper "sometimes" have a different behaviour when approaching the AccurateRip database.
On this cd CueRipper is using the CRC column values while EAC is using the V2 column values.

Now I know at least.

I believe that [%unique%] string [It did add 1 to the ripped files so that this time did not overwrite the previous rip] or better the %music%\%artist%\[%year% - ]%album%\%artist% - %album%[ '('disc %discnumberandname%')'].cue should be "by default" if anyone ripping double cd's or boxsets might be having the very same issue just out of the box after installing the software and ripping a double cd for the very first time.
Thanks for the tip.

And yes. Unfortunately also 2.1.5 seems to be having the same issue you pointed out for 2.1.4 when it comes to cd's including an extra data track, videos or anything.
It looks like the cdextra type is causing some conflicts.
If this is related to (some) LG drives (I am having 4 at the moment) I cannot tell.

Also if the cd has some scratches it tends to give an error message box on some drives. If I select quit the program will close without saving. If i click on Continue it will carry on writing.
Maybe I don't need to be scared by those menacing messages when dealing with a scratched cd that will be eventually ripped with other software without the "menacing" boxes with one option meaning the end of the whole process.

That's why I go back to EAC/dbPowerAmp/sometimes also iTunes when dealing with problematic cd's until I collect the right samples (if I can and if the AccurateRip database has a reliable amount of submissions). Not all of them though.

Is the FLAGS PRE of the older cd's will get fixed it will be an extra step into perfection at this point.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-09-30 21:29:01
Quote
Is the FLAGS PRE of the older cd's will get fixed it will be an extra step into perfection at this point.
Do you have Detect Indexes (http://www.cuetools.net/wiki/CUERipper_Options#Extraction) set to False?

Note: This is a different version of the CD [DISCID 650A1907 <> DISCID 620A1807] (it took me a while to dig it out).
Used drive  : LG HL-DT-ST DVDRAM GH24NS95

Set to True
Code: [Select]
REM DISCID 620A1807
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
CATALOG 0042282966322
REM DATE 1979
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov"
FILE "Vangelis - Opera Sauvage.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Vangelis"
    TITLE "Hymne"
    FLAGS PRE
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    PERFORMER "Vangelis"
    TITLE "Rêve"
    FLAGS PRE
    INDEX 00 02:41:27
    INDEX 01 02:45:72
  TRACK 03 AUDIO
    PERFORMER "Vangelis"
    TITLE "L'enfant"
    FLAGS PRE
    INDEX 00 15:12:62
    INDEX 01 15:18:22
...
Set to False
Code: [Select]
REM DISCID 620A1807
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
CATALOG 0042282966322
REM DATE 1979
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov"
FILE "Vangelis - Opera Sauvage.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Vangelis"
    TITLE "Hymne"
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    PERFORMER "Vangelis"
    TITLE "Rêve"
    INDEX 01 02:45:72
  TRACK 03 AUDIO
    PERFORMER "Vangelis"
    TITLE "L'enfant"
    INDEX 01 15:18:22
...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dadadacicici on 2015-10-01 22:22:44
Detect Indexes is set to True (as for defaults when I installed CueTools). Something I have left untouched as advised.
Your version is a different pressing of course but if it did detect the pre-emphasis using the same settings I am also using.
Perhaps the FLAGS PRE is written in a different place...

Quote
A pre-emphasis flag for each track is normally stored in the subcode along with the audio data. It's also supposed to be stored in the table of contents (TOC), but many CDs have TOCs that say there's no pre-emphasis when in fact the subcode says there is. There are also some CDs which people believe were mastered with pre-emphasis, but which have no pre-emphasis flags set at all.


... and this might be the case... and the reason why I hate buying represses...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-10-02 00:00:30
Maybe korth will provide a snippet of audio from his CD. You can compare it to the same section on yours.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-10-02 13:09:00
A quick question regarding tagging:

(http://i.snag.gy/JQXtu.jpg)

I'm encoding a soundtrack album. Movie has been released in 1952, while this album has been released in 2007.

My questions are:

1) What exactly is the meaning of "Date" and "Release Date"?
2) Would be correct to set Date to 1952 and Release Date to 2007?

What about foobar:

(http://i.snag.gy/lXCyV.jpg)

What would be the meaning of Date tag, in that case?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2015-10-02 13:15:28
Release date is for the actual CD release date - for example, every remaster has a different one, so you can tell them apart. So it's probably 2007.
Date is usually the earliest release date for this material. Which is kind of ambiguous in this case, because the movie doesn't quite count as a release, so strictly speaking this would have to be 2001, but in the end it's your choice and if 1952 makes more sense for you, go with it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pidgeon on 2015-10-02 13:20:02
Thank you Gregory. Do you know if, talking about movie soundtracks, the majority of people use the movie date as Date (Year) tag?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2015-10-02 18:31:17
I'd say it's whatever you make it to be. I usually just tag the date as yyyy/mm/dd of the release for all my archives.

@Gregory: any chance you could look at this issue?

I'm currently running CUETools on WINE and it somewhat works (did not try CUERipper yet), but it's full of weird side effects. For example mounting /tmp as R:\ then attempting to access R:\ via CUETools results in  "The given path's format is not supported". Going via the internal Z: drive gives something similar: "Z:\tmp - the given path's format is not supported". foobar2000 can access the same folder on WINE just fine.


Regarding this issue, I was able to pinpoint what is causing it: if any of the files in the folder you are trying to browse contain invalid characters by NTFS definition (in my case, ':' in socket file names in /tmp), then CUETools cannot list anything and just spits out that message.
I would be eternally grateful if CUETools could ignore and simply not show (=filter out) invalid filenames instead.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: vayra on 2015-10-20 05:36:26
Hello, I am trying to convert my CD collection in flac files, but I would like to do from the command line through a batch file. where can I find a guide? thanks and sorry for my terrible English!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-10-20 23:25:35
Sorry, no guide.
Are you converting image+cue to tracks?
Example: image.flac + image.cue to track1.flac + track2.flac + track3.flac ...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: vayra on 2015-10-23 12:25:48
Sorry, no guide.
Are you converting image+cue to tracks?
Example: image.flac + image.cue to track1.flac + track2.flac + track3.flac ...

yes, I would like to rip CDs into folders with track.flac, track2.flac etc. via command line, as I could do? thank
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-10-23 12:30:36
Do you have file(s) + .cue you are trying to 'convert'? Or are you trying to 'rip' CDs?
'convert' and 'rip' are different things.
You can 'convert' existing audio files (already ripped from CD) to FLAC via command-line using CUETools.exe if you have a CUE file. I could write a quick guide for that.
The command-line CUETools.ConsoleRipper.exe is a very basic program for testing so it won't 'rip' the way you want.
As far as I know CUERipper.exe does not have command-line options.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: knubbze on 2015-10-23 16:49:36
Feature request:
POSTGAP support


What is POSTGAP? Just curious.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-10-23 17:19:51
It is a CUE sheet command to add silence after a track.
http://digitalx.org/cue-sheet/syntax/#postgap (http://digitalx.org/cue-sheet/syntax/#postgap)
cdrwin supports the command but I'm not sure if other programs do also.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: knubbze on 2015-10-24 19:32:44
It is a CUE sheet command to add silence after a track.
http://digitalx.org/cue-sheet/syntax/#postgap (http://digitalx.org/cue-sheet/syntax/#postgap)
cdrwin supports the command but I'm not sure if other programs do also.


I see; so not relevant to CD ripping then?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2015-10-25 02:22:39
It's relevant to checking against alternate structures which is useful if you have a rare pressing.  So, yes, it is just as relevant to "ripping" as any other instruction.

FWIW, Alcohol 120% supports postgap lines (in response to korth's comment).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-10-25 03:52:29
Yes that should've been 'which other programs' instead of 'if'.
ImgBurn supports postgap as well.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: vayra on 2015-10-25 08:14:12
Do you have file(s) + .cue you are trying to 'convert'? Or are you trying to 'rip' CDs?
'convert' and 'rip' are different things.
You can 'convert' existing audio files (already ripped from CD) to FLAC via command-line using CUETools.exe if you have a CUE file. I could write a quick guide for that.
The command-line CUETools.ConsoleRipper.exe is a very basic program for testing so it won't 'rip' the way you want.
As far as I know CUERipper.exe does not have command-line options.

using cue console ripper get a .wav file and .cue file, then I would get from these .flac files via the command line. guide would be welcome !!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rkjnsn on 2015-10-25 23:54:22
I have a couple of feature requests for CUERipper. Hopefully this is the right spot for them.

Unfortunately, this thread has gotten a bit long, so if these are repeats, I apologize. In that case consider it a vote for the feature. 


The first should be, I think, relatively simple:

A lot of times when reading a damaged disc, I will get spurious errors, such as "medium error" or "ioctl failed". I say spurious because these errors don't always happen for a given disc, usually aren't at the same spot, and often happen after several retries have already been performed on the same location.

Unfortunately, when one of these errors occurs, CUERipper just aborts the rip. It would be very nice if there were an option to retry the operation instead of aborting, since in my experience, it would be very likely to succeed given a second attempt. If no progress is made after many retries, it might be nice if there were additionally an option to skip the problem-causing sector, using the best guess from any retries that have been completed, and continue on ripping the rest of the disc.


The second is more complex, and may be beyond the scope of CUERipper:

For extra-problematic discs, it would be nice if there were functionality akin to that found it ddrescue. The idea would be for CUERipper to record which samples were not read correctly, and allow retrying just the failed samples at a later date to try to get as much data as possible from the CD (possibly crossing the threshold from not repairable to repairable). The idea would be that I could rip a CD on one drive, and then retry the failed samples on one or more other drives to try to get as much valid data as possible from the CD.


Finally, I had one disc with very slight damage that was such that the drive would kind of get lost when it got to a certain track, and keep returning read failures after that point. I discovered (using a different tool) that if I read some data from the track afterword and then went back and tried again (so the drive was seeking backward and not forward), it read the track just fine. I'm not sure if this is common enough to be useful as a strategy for error correction, but I thought I'd mention it.

Thanks!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: AMRoberts on 2015-10-27 16:26:19
New user attempting to use CUERipper ... This thread seems current, but someone please let me know if I should put this elsewhere.  I'm encountering:
[blockquote]Exception: Error Reading CD: IoctlFailed[/blockquote]in a fashion which seems different from what I've been able to find by searching.

I've been an EAC user on an old machine at home that is failing, so I've brought up a new platform and wanted to try CUERipper at the same time.  The new platform is:
my discs for testing are Pink Floyd, The Wall (Columbia, C2K 36183).  Previously ripped years ago via EAC, sitting on an indoor shelf ever since. I recently learned that these discs were recorded with pre-emphasis that is only indicated in the track data, which EAC didn't detect and indicate in my log.  Wanted to see CUERipper report it (and then experiment with fixing it).

So I launched CUERipper, and loaded a disc once the window was up.  CUERipper identified the read offset (matching what I had seen in a web site search for this drive), read the disc metadata and track titles, and finds 30 CUETools DB matches and 78 AccurateRip matches.  This is looking very promising!

Hit the "Go" button ... Status bar shows Detecting drive features ... followed by Detecting gaps ...  After gap detection completes I see Ripping @nn.mm ..., then Ripping @nn.mm (retry 1)... (if I understand correctly, retry because I'm in "Secure" mode?), then shortly after it switches back to another Ripping @nn.mm ... (Track #2?) the rip fails with the Error reading CD.  Checking the folder I see only the .CUE file.  This seems to be deterministic behavior on both discs.

Switched off Test & Copy, repeated the experiment.  This gets me further into the rip before encountering the error.  The alternation between Ripping and Ripping (retry 1) was still happening, 4-8 times (across multiple tests), but when I check the target folder I see only the .CUE file and sometimes 01. In the Flesh_.flac (note that CUERipper shows the track title as In the Flesh?, so the file name in the folder differs slightly from the %tracknumber%. %title% template in the options).  When it fails only 4-5 alternations (tracks?) into the rip I see just the .CUE file, if it goes further I see the .CUE and a single FLAC.  Haven't ever seen more than the first track's FLAC file.

Similar results on the other disc in the set.  The behavior isn't deterministic, how deep into the rip I get varies (as long as Test & Copy is not selected).  Changing to either Burst or Paranoid mode seems to make the failure happen sooner.

So I'm hoping this is a known problem with known solutions to try, and my "Google-fu" just isn't good enough to find them.  Failing that, if anyone involved in CUERipper development can tell me how to enable more logging or debug information to get some traction on the problem, I'll certainly willing to give it a go.  I'll also do an EAC installation on the VM and give it a try this evening, to see if the drive fails to work with any ripping software.

Thanks in advance for any advice or pointers,
Alan
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: mjb2006 on 2015-10-27 23:30:37
Indeed, secure mode involves a minimum of 2 reads of each block of sectors, and for the 2nd pass, the "retry" message is an unfortunate word choice since it implies there was something wrong with the first pass. Nothing to worry about, though.

The filename thing is not a bug. Windows APIs don't support "?" in filenames, so if constructing a filename from a string with "?" in it, the app must decide what to write instead. EAC makes a decision as well, with some degree of configurability.

Secure mode is already doing at least 2 reads, so Test & Copy is putting unnecessary wear & tear on your drive. I would only use it when using burst mode on CDs which are not in AccurateRip or CTDB.

The rips should not be aborting unless there's a communication problem with the drive.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2015-10-27 23:55:15
I recently learned that these discs were recorded with pre-emphasis that is only indicated in the track data, which EAC didn't detect and indicate in my log.

EAC indicating pre-emphasis in a log, is this a new feature or something?  It surely didn't do it with versions prior to 1.0.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: AMRoberts on 2015-10-28 15:38:56
Indeed, secure mode involves a minimum of 2 reads ... The filename thing is not a bug. ... so Test & Copy is putting unnecessary wear & tear on your drive. ...

Understood, and thanks for the confirmation that I mostly understand what I was seeing.

Quote
The rips should not be aborting unless there's a communication problem with the drive.

Well I've now installed EAC on the same platform, and it has ripped both discs of The Wall and Brubeck's Time Further Out flawlessly (i.e., all tracks extracted and converted to FLAC, metadata and cover art found and used, AccurateRip verified). 

So the external USB drive, attached to QNAP, made available to the Win7 VM works, but CUERipper-the-application has a problem with it for some reason.  That is where I'm hoping for any suggestions to gain traction on ... Logging, debug mode, anything else I can do.  Could be as simple as I'm missing something or am misconfigured.  The instructions in the wiki said unpack the folder no setup required, so that is all I did.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: AMRoberts on 2015-10-28 15:59:11
EAC indicating pre-emphasis in a log, is this a new feature or something?  It surely didn't do it with versions prior to 1.0.

Sorry if my post wasn't clear ... One of the many reasons I would like to get CUERipper operational is that the generated CUE file is supposed to indicate pre-emphasis if it is flagged either in the TOC or the per-track subcode.  From online reading my understanding is that a CD mastered with pre-emphasis ought to have that indicated with a flag in the TOC, but there are some in the wild where it is only indicated in the subcode.

I can't find the reference at the moment, but I believe that really old versions of EAC could check/report all the detail from both TOC and subcode, but Andre Wiethoff had to remove some of this functionality because of concerns related to EU DRM regulations.  Per this chart (http://wiki.hydrogenaud.io/index.php?title=Comparison_of_CD_rippers#Comparison_chart), the current version of EAC reports pre-emphasis TOC-only, while CUERipper is listed as reporting TOC and subcode.

I'm not clear on whether EAC's indication of TOC-flagged pre-emphasis is just somewhere on the UI, or in the log, or if you have to generate a CUE file.  For CUERipper it seems to be in the CUE file (even though CUERipper is failing to rip for me right now, it does produce a CUE file).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2015-10-28 16:38:00
From online reading my understanding is that a CD mastered with pre-emphasis ought to have that indicated with a flag in the TOC, but there are some in the wild where it is only indicated in the subcode.

I can't find the reference at the moment, but I believe that really old versions of EAC could check/report all the detail from both TOC and subcode, but Andre Wiethoff had to remove some of this functionality because of concerns related to EU DRM regulations.

Unfortunately I don't have any of the dozen or so titles listed here (http://www.studio-nibble.com/cd/index.php?title=Pre-emphasis_%28release_list%29) to verify for myself, but I have read about this.

I'm not clear on whether EAC's indication of TOC-flagged pre-emphasis is just somewhere on the UI, or in the log, or if you have to generate a CUE file.

Unless it has recently been changed, pre-emphasis is displayed in both the GUI and the cue sheet, but not the log file.

It would be nice to have it in the log file, since cue sheets aren't all that useful for most people who keep one track per file and have no intention to burn duplicates with sub-channel information or check their lossless sources against the AR/CT databases.  Unfortunately, cue sheets are still required if you want a written record indicating the existence of pre-emphasis.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: AMRoberts on 2015-10-29 13:50:10
Unfortunately I don't have any of the dozen or so titles listed here (http://www.studio-nibble.com/cd/index.php?title=Pre-emphasis_%28release_list%29) to verify for myself, but I have read about this.

I had seen that page before but had lost track of it, thanks for the pointer.  Unless I just haven't had enough coffee yet this morning  , it doesn't list the 1979 Columbia/CBS edition of The Wall (C2K 36183).  This page (https://www.quora.com/What-is-the-best-version-of-The-Wall-by-Pink-Floyd) calls out that release as having pre-emphasis, so I've been testing with my copy.

EAC V1.1 reports "No" pre-emphasis for each track of both discs, but I don't believe EAC is checking the subcode.  While I haven't been successful at getting CUERipper to actually rip on my platform, it does gap-detect and create a CUE file before it starts ripping (and then fails).  The CUE is consistently saying FLAGS PRE for each track, as in:

Code: [Select]
  TRACK 01 AUDIO
    FLAGS PRE
    PERFORMER "Pink Floyd"
    TITLE "In the Flesh?"
    INDEX 01 00:00:00
    ...

So I think it is an example of the flag missing from the TOC (where EAC would have indicated it), but present in the subcode?

Quote
It would be nice to have it in the log file, since cue sheets aren't all that useful for most people who keep one track per file ...

I agree with your point, but it would only be reliable (from the standpoint of breaking out SoX deemph or some other tool to correct it post-rip) if the log reported pre-emphasis flag(s) from both the TOC and the subcode, correct?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2015-10-29 14:18:23
So I think it is an example of the flag missing from the TOC (where EAC would have indicated it), but present in the subcode?
Yes.
Quote
I agree with your point, but it would only be reliable (from the standpoint of breaking out SoX deemph or some other tool to correct it post-rip) if the log reported pre-emphasis flag(s) from both the TOC and the subcode, correct?
More reliable, yes.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: A.G. on 2015-10-30 13:03:48
Hello!
I found a bug in the CueTools.Flake.exe
I am converting files from various formats to flac using Flake encoder included in CueTools (CUETools.Flake.exe)
After encoding some files (not everyone) I get MD5 hash error ("Ошибка верификации").
When I verify it with reference flac.exe I get "ERROR, MD5 signature mismatch"
My command line is: -11 --lax -b 4608 -t "search" -s "search" -r 8 --vbr 4 -l 32 -m "akaike" -e 32 --window-method search --max-precision 1,1 -P 0
I found that encoded file gets corrupted when using --vbr 4. Without this option I get no errors.

I uploaded one WAV track to the share
https://drive.google.com/file/d/0BzoOc80ZSA...iew?usp=sharing (https://drive.google.com/file/d/0BzoOc80ZSAXEcXZZb1JNczJObFE/view?usp=sharing)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: remenor on 2015-10-30 18:42:50
New user attempting to use CUERipper ... This thread seems current, but someone please let me know if I should put this elsewhere.  I'm encountering:
[blockquote]Exception: Error Reading CD: IoctlFailed[/blockquote]in a fashion which seems different from what I've been able to find by searching.

I've been an EAC user on an old machine at home that is failing, so I've brought up a new platform and wanted to try CUERipper at the same time.  The new platform is:
  • A virtual machine running Win7 Home Premium x64 SP1, 6GB of RAM
  • The VM is hosted on a QNAP TS-451 NAS (x86 dual-core CPU, host OS is "QTS 4.1.4")
  • Lite-On eTDU108 external DVD-ROM, USB 2 connection to the TS-451 (no outboard hub), drive assigned to the VM
  • CUETools 2.1.5, downloaded this morning. Stock configuration except for: Option changes for metadata search - extensive, detailed log - true; changed from image to tracks mode; set Test & Copy; and changed output path template
my discs for testing are Pink Floyd, The Wall (Columbia, C2K 36183).  Previously ripped years ago via EAC, sitting on an indoor shelf ever since. I recently learned that these discs were recorded with pre-emphasis that is only indicated in the track data, which EAC didn't detect and indicate in my log.  Wanted to see CUERipper report it (and then experiment with fixing it).

So I launched CUERipper, and loaded a disc once the window was up.  CUERipper identified the read offset (matching what I had seen in a web site search for this drive), read the disc metadata and track titles, and finds 30 CUETools DB matches and 78 AccurateRip matches.  This is looking very promising!

Hit the "Go" button ... Status bar shows Detecting drive features ... followed by Detecting gaps ...  After gap detection completes I see Ripping @nn.mm ..., then Ripping @nn.mm (retry 1)... (if I understand correctly, retry because I'm in "Secure" mode?), then shortly after it switches back to another Ripping @nn.mm ... (Track #2?) the rip fails with the Error reading CD.  Checking the folder I see only the .CUE file.  This seems to be deterministic behavior on both discs.

Switched off Test & Copy, repeated the experiment.  This gets me further into the rip before encountering the error.  The alternation between Ripping and Ripping (retry 1) was still happening, 4-8 times (across multiple tests), but when I check the target folder I see only the .CUE file and sometimes 01. In the Flesh_.flac (note that CUERipper shows the track title as In the Flesh?, so the file name in the folder differs slightly from the %tracknumber%. %title% template in the options).  When it fails only 4-5 alternations (tracks?) into the rip I see just the .CUE file, if it goes further I see the .CUE and a single FLAC.  Haven't ever seen more than the first track's FLAC file.

Similar results on the other disc in the set.  The behavior isn't deterministic, how deep into the rip I get varies (as long as Test & Copy is not selected).  Changing to either Burst or Paranoid mode seems to make the failure happen sooner.

So I'm hoping this is a known problem with known solutions to try, and my "Google-fu" just isn't good enough to find them.  Failing that, if anyone involved in CUERipper development can tell me how to enable more logging or debug information to get some traction on the problem, I'll certainly willing to give it a go.  I'll also do an EAC installation on the VM and give it a try this evening, to see if the drive fails to work with any ripping software.

Thanks in advance for any advice or pointers,
Alan


I have not the solution. But I have the same problem. Cueripper on Linux (under Wine) behaves exactly like (Cuetools works perfectly)
I guess the Linux kernel (most NAS implement Linux) does not support certain calls (from Cueripper) to the device. Or that the VM (and Wine) do not correctly translate these calls...
Maybe someone who knows about low-level code can respond
Sorry for my english
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: AMRoberts on 2015-11-06 17:06:25
I have not the solution. But I have the same problem. Cueripper on Linux (under Wine) behaves exactly like (Cuetools works perfectly)
I guess the Linux kernel (most NAS implement Linux) does not support certain calls (from Cueripper) to the device. Or that the VM (and Wine) do not correctly translate these calls...
Maybe someone who knows about low-level code can respond


remenor,

I think my NAS is using KVM/qemu for supporting VMs, but I don't have anywhere near enough Linux depth to tell you how different or common that would be with the Wine code.

Since my failure point is variable, I suspect something modal/timing-related, where a returned status isn't translated correctly, or CUEripper's logic attempts some API call that doesn't work for the first time during a rip (as a made-up example:  reducing speed for a retry attempt). If the problem was just an unsupported call that is part of CUEripper's normal sequence of events, I would expect my failure point to be completely consistent.

I was also hoping for some guidance on how to debug this problem, but I've looked at the history on the source repository, and there doesn't seem to be any action after 2015-02-25 (most changes seem to be 2014 or older).  Could be that the developer(s) are otherwise occupied.

I entertained the notion that I might be able to find and enable any code in the application for additional logging, so I borrowed a machine with Visual Studio 2012, downloaded a local version of the code, and attempted to build the project.  Unfortunately VS2012 griped about having to convert from a VS2010 project type, and after doing that generated 30+ errors and 80+ warnings.  This isn't really in my skill set, I don't think I'll be able to get to a clean build.  I assume from the wiki that its a .NET application, and AFAIK .NET is such an expansive collection of libraries that "learning cliff" may be a more appropriate term than "learning curve."  If you happen to have .NET skills, you might find the source more useful than I did.

Fortunately I'm not completely out of luck, since EAC is working in my environment.  You might try EAC on Wine if you don't have any other ripping solution.

Regards,
Alan
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SF01 on 2015-12-08 21:51:57
I have a serious problem!

I would like to report a bug.

The Cuetools plug in for EAC treats those albums:
http://www.metal-archives.com/albums/Moonl...of_Guilt/491107 (http://www.metal-archives.com/albums/Moonlight/Integrated_in_the_System_of_Guilt/491107)
http://www.metal-archives.com/albums/Moonl...of_Guilt/134588 (http://www.metal-archives.com/albums/Moonlight/Integrated_in_the_System_of_Guilt/134588)

As identical discs and while ripping the english-language version the plugin compares the results with polish-version, thus making all as "No match", the same occurs with accuraterip plugin in EAC, it compares those two discs, so the obcious result is, that the second tip is inaccurate entirely.

So CTDB plug-in has serious issues with albums that were released with vocals in different languages, seriously, is the same bug present on Kraftwerk's Komputerwelt/Computerworld when ripping those separate CDs with the same music, but different vocals?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-12-08 22:30:05
If the two versions use the same CD layout (same TOC (https://musicbrainz.org/cdtoc/7s3dME6Ni.oRv7VT7LCDv1eHhBI-)) then both CD versions will be stored under the same AccurateRip ID and the same CTDB TOCID but with different checksums. If one of the CD versions shows zero results then likely no one has submitted that one yet.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: spoon on 2015-12-08 23:52:22
Also when enough people submit this 2nd disc, they will both co-exist in AccurateRip.

It is not a bug, just your disc is not yet in the database.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SF01 on 2015-12-09 13:02:32
As fot the Polish version, the Accuraterip confidence was 2, and the disk was not present in CTDB database, so it was uploaded.
The englidh version had confidence 2 claiming that the whole rip is inaccurate, but it did mention that the pressing might be different, which is obvious, as those are two different albums, the CTDB results were "(0/1) No match".

Full logs I can add, if it would be useful.

Both CDs ripped properly, so my post was just a notification of the issue.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2015-12-09 15:03:02
The English version was also submitted to the CTDB.

The (partial) AccurateRip ID for BOTH versions is 0011e2c9-00775798-6a0e1008
The CTDB TOCID for BOTH versions is JFlEmyJUDSuIMKB0KPRyGf7V_uU-
Because the TOCs match, BOTH versions of the CD coexist under the same ID. This is not a bug.

When you ripped the second CD, the CTDB compared it to the first CD (which it found under the same TOCID and did not match) so you received "(0/1) No match" and the second CD was submitted.
If you were to re-rip both CDs right now the CTDB results would be "(1/2) Accurately ripped" for both CDs (assuming the re-rip matched the original and no one else submitted one of the versions) and the Submit result would be "Already Submitted".

Both versions of the CD will also coexist in the AccurateRip DB under the same ID (not a bug) once the English version gets added. It appears that only the Polish version may exist right now.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-12-09 15:07:19
As fot the Polish version, the Accuraterip confidence was 2, and the disk was not present in CTDB database, so it was uploaded.
The englidh version had confidence 2 claiming that the whole rip is inaccurate, but it did mention that the pressing might be different, which is obvious, as those are two different albums, the CTDB results were "(0/1) No match".


That is not a "bug", it is just that the "Inaccurate" term is sometimes imprecise. You ask the databases to have human knowledge on why the audio signal is different.

If you press/burn two three CDs with the same table-of-contents, where
-> CD#2 is like CD#1 except you have used sandpaper on it and gotten an unbelievable number of errors, and
-> CD#3 simply has a different audio signal,
then all the database can know, is that the CDs have the same table-of-contents and different audio.

What if you took CD#3 and ran it through a DSP? An EQ? A karaoke effect array?  The databases cannot know.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SF01 on 2015-12-09 15:46:42
Thus the mechanisms of database should be made more precise to distinguish two CDs with different music, but the same TOC.

I will not rerip it several times, so that databases would have few results, I could however rip them form several different workstations, or hope more people will tip their CDs and submit them to database...

The important thing is, there were no errors during ripping, so tracks are of avveptable quality, considering they are mp3s...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2015-12-09 15:54:50
Thus the mechanisms of database should be made more precise to distinguish two CDs with different music, but the same TOC.


It is not useful for what AccurateRip is good for, namely to verify that someone has gotten the same as you. It is only good for explaining why someone got something different. 

And while it is likely doable now, as audio fingerprint algorithms are getting better, there is no way you can retro-fit audio into old entries anyway.



I will not rerip it several times, so that databases would have few results, I could however rip them form several different workstations


You will not but you however still will ... ?


The important thing is, there were no errors during ripping


Again, AccurateRip cannot verify that unless someone has gotten the same result. If the result is different for whatever reason, it cannot verify.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: zoomorph on 2016-01-01 03:37:57
CUETools is failing, reporting L-EC Uncorrectable Error on one track.

Feature requests:
- Option to skip this error and still rip as much of the track as possible (if possible?)
- Option to skip track / select which tracks are ripped.

I've downloaded the source code for CUETools and modified it to skip the track throwing the error. I will see if I can also find a way to ignore this error.
Title: CUERipper not detecting gaps
Post by: knubbze on 2016-01-18 09:31:10
I'm soon to embark on an archival project involving securely (as possible) ripping hundreds of precious audio CDs. Before I start properly, I've been trialing a few different 'secure' ripping utilties, and I really like the feature set, as well as the simplicity of CUERipper, but I've already encountered an issue on one of the first CDs I've tried to rip.

Basically, CUERipper seems to be unable to detect the gaps on the CD in question, which is a normal factory-pressed disc (http://www.discogs.com/Maximillian-Deeper-Than-Most/release/7106549). So I then tried ripping the disc in Exact Audio Copy, which was able to detect the gaps.

I've uploaded the logs from each program:

CUERipper (http://pastebin.com/hnvhHhpA)
Exact Audio Copy (http://pastebin.com/JbXXxCXL)

Does anybody know why CUERipper is not detecting the gaps? It's a shame because I was hoping to rely on CUERipper as my primary CD ripping tool.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: bilbo on 2016-01-18 16:35:06
@knubbze     Since both programs are doing the same thing, "appending gaps to previous track", I don't understand the problem. Is there a reasion that you must have the length of the gap?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: knubbze on 2016-01-18 17:07:37
@knubbze     Since both programs are doing the same thing, "appending gaps to previous track", I don't understand the problem. Is there a reasion that you must have the length of the gap?

Well, I just wanted a perfect (as is possible) replication of the audio CDs, in case  ever want to burn a copy in the future (unlikely, but possible). For this particular CD with 'standard' gaps you are correct that it doesn't really matter, but in cases where CDs have 'index 0' pregaps (i.e. this CD (http://comments.gmane.org/gmane.comp.audio.eac.user/9710)), I figured that it may be a problem.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2016-01-18 17:10:56
Some have indices > 1 as well. ;)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Isabelxxx on 2016-03-29 19:48:36
*looks at page count and recalls staggering number of topic changes in this thread*
*considers possibility that greynol is joking*

Anyway, perhaps I should be more direct:

CUETools warning the user that the audio is not Red Book is good, but refusing to operate on it seems like an unnecessary restriction.

Agree 100%.

Same problem today, I was going to split a hires file and I can't do it with Cuetools just because the program is restricted to reedbook. (!) But at the same time I can use ALL the lossless encoders from same program to work with those hires files... makes no sense to me.

I hope lifting that restriction will be taken into consideration too.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: CrusherW9 on 2016-04-08 02:35:56
Does anyone happen to know why I can rip a CD just fine but when I rip a CD through a Windows 7 VM, none of the rips verify as accurate? The VM is a guest of the machine that rips the CD accurately so all of the hardware is the same and I manually entered the proper drive offset in the VM.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-04-08 05:43:28
I manually entered the proper drive offset in the VM.
Are you sure the VM environment is providing direct access to that drive? An emulated drive will likely have a different read offset.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: CrusherW9 on 2016-04-12 01:05:32
I have the 'passthrough' box checked in VirtualBox. I'm not sure if it's possible for it to work properly through a VM, though I'm hoping it is. Was just wondering if anyone had tried this before or had any ideas.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-04-13 12:20:04
Hi, I noticed that this rip, which includes silent tracks (Tool - 1993 - Undertow), is reported as "no match" in .accurip log+"not accurate" in batch while it should report "silent track" in .accurip log and "accurate" in batch. (Edit: I erased the irrelevant part of the log as it exceeded HA character limit)

Code: [Select]
[CUETools log; Date: 13/04/16 12:57:57; Version: 2.1.6]
Pregap length 00:00:32.
[CTDB TOCID: 46Yj4k_u4vklxp6jffKA7XTpdz8-] found.
        [ CTDBID ] Status
        [799328b1] (47/56) Accurately ripped
        [ae45bea5] (05/56) No match
        [9f7ef995] (01/56) No match
        [beb370ec] (01/56) No match
        [4a3da3b1] (01/56) No match
        [d78732a7] (01/56) No match
Track | CTDB Status
  1   | (55/56) Accurately ripped
  2   | (55/56) Accurately ripped
  3   | (55/56) Accurately ripped
  4   | (50/56) Accurately ripped
  5   | (51/56) Accurately ripped
  6   | (51/56) Accurately ripped
  7   | (50/56) Accurately ripped
  8   | (50/56) Accurately ripped
  9   | (50/56) Accurately ripped
 10   | (56/56) Accurately ripped
 11   | (56/56) Accurately ripped
 12   | (56/56) Accurately ripped
 13   | (56/56) Accurately ripped
 14   | (56/56) Accurately ripped
 15   | (56/56) Accurately ripped
 16   | (56/56) Accurately ripped
 17   | (56/56) Accurately ripped
 18   | (56/56) Accurately ripped
 19   | (56/56) Accurately ripped
 20   | (56/56) Accurately ripped
 21   | (56/56) Accurately ripped
 22   | (56/56) Accurately ripped
 23   | (56/56) Accurately ripped
 24   | (56/56) Accurately ripped
 25   | (56/56) Accurately ripped
 26   | (56/56) Accurately ripped
 27   | (56/56) Accurately ripped
 28   | (56/56) Accurately ripped
 29   | (56/56) Accurately ripped
 30   | (56/56) Accurately ripped
 31   | (56/56) Accurately ripped
 32   | (56/56) Accurately ripped
 33   | (56/56) Accurately ripped
 34   | (56/56) Accurately ripped
 35   | (56/56) Accurately ripped
 36   | (56/56) Accurately ripped
 37   | (56/56) Accurately ripped
 38   | (56/56) Accurately ripped
 39   | (56/56) Accurately ripped
 40   | (56/56) Accurately ripped
 41   | (56/56) Accurately ripped
 42   | (56/56) Accurately ripped
 43   | (56/56) Accurately ripped
 44   | (56/56) Accurately ripped
 45   | (56/56) Accurately ripped
 46   | (56/56) Accurately ripped
 47   | (56/56) Accurately ripped
 48   | (56/56) Accurately ripped
 49   | (56/56) Accurately ripped
 50   | (56/56) Accurately ripped
 51   | (56/56) Accurately ripped
 52   | (56/56) Accurately ripped
 53   | (56/56) Accurately ripped
 54   | (56/56) Accurately ripped
 55   | (56/56) Accurately ripped
 56   | (56/56) Accurately ripped
 57   | (56/56) Accurately ripped
 58   | (56/56) Accurately ripped
 59   | (56/56) Accurately ripped
 60   | (56/56) Accurately ripped
 61   | (56/56) Accurately ripped
 62   | (56/56) Accurately ripped
 63   | (56/56) Accurately ripped
 64   | (56/56) Accurately ripped
 65   | (56/56) Accurately ripped
 66   | (56/56) Accurately ripped
 67   | (56/56) Accurately ripped
 68   | (56/56) Accurately ripped
 69   | (47/56) Accurately ripped
[AccurateRip ID: 00ec3b4e-235f416b-f5103945] found.
Track   [  CRC   |   V2   ] Status
 01     [c0c34995|09769895] (116+115/264) Accurately ripped
 02     [aeb6547d|96b02e49] (115+115/263) Accurately ripped
 03     [13b8ed3c|7470b6ad] (115+117/265) Accurately ripped
 04     [6762b4e4|afc5e9d6] (112+114/259) Accurately ripped
 05     [a0624b25|98a367e3] (115+112/259) Accurately ripped
 06     [06771493|83cb0d49] (116+112/260) Accurately ripped
 07     [489e30f0|ee728ba7] (116+112/260) Accurately ripped
 08     [a008a206|df0d3415] (115+111/258) Accurately ripped
 09     [9cd0ce0f|4cb7d730] (115+111/258) Accurately ripped
 10     [00000000|00000000] (000+000/001) No match
 11     [00000000|00000000] (000+000/001) No match
 12     [00000000|00000000] (000+000/001) No match
 13     [00000000|00000000] (000+000/001) No match
 14     [00000000|00000000] (000+000/001) No match
 15     [00000000|00000000] (000+000/001) No match
 16     [00000000|00000000] (000+000/001) No match
 17     [00000000|00000000] (000+000/001) No match
 18     [00000000|00000000] (000+000/001) No match
 19     [00000000|00000000] (000+000/001) No match
 20     [00000000|00000000] (000+000/001) No match
 21     [00000000|00000000] (000+000/001) No match
 22     [00000000|00000000] (000+000/001) No match
 23     [00000000|00000000] (000+000/001) No match
 24     [00000000|00000000] (000+000/001) No match
 25     [00000000|00000000] (000+000/001) No match
 26     [00000000|00000000] (000+000/001) No match
 27     [00000000|00000000] (000+000/001) No match
 28     [00000000|00000000] (000+000/001) No match
 29     [00000000|00000000] (000+000/001) No match
 30     [00000000|00000000] (000+000/001) No match
 31     [00000000|00000000] (000+000/001) No match
 32     [00000000|00000000] (000+000/001) No match
 33     [00000000|00000000] (000+000/001) No match
 34     [00000000|00000000] (000+000/001) No match
 35     [00000000|00000000] (000+000/001) No match
 36     [00000000|00000000] (000+000/001) No match
 37     [00000000|00000000] (000+000/001) No match
 38     [00000000|00000000] (000+000/001) No match
 39     [00000000|00000000] (000+000/001) No match
 40     [00000000|00000000] (000+000/001) No match
 41     [00000000|00000000] (000+000/001) No match
 42     [00000000|00000000] (000+000/001) No match
 43     [00000000|00000000] (000+000/001) No match
 44     [00000000|00000000] (000+000/001) No match
 45     [00000000|00000000] (000+000/001) No match
 46     [00000000|00000000] (000+000/001) No match
 47     [00000000|00000000] (000+000/001) No match
 48     [00000000|00000000] (000+000/001) No match
 49     [00000000|00000000] (000+000/001) No match
 50     [00000000|00000000] (000+000/001) No match
 51     [00000000|00000000] (000+000/001) No match
 52     [00000000|00000000] (000+000/001) No match
 53     [00000000|00000000] (000+000/001) No match
 54     [00000000|00000000] (000+000/001) No match
 55     [00000000|00000000] (000+000/001) No match
 56     [00000000|00000000] (000+000/001) No match
 57     [00000000|00000000] (000+000/001) No match
 58     [00000000|00000000] (000+000/001) No match
 59     [00000000|00000000] (000+000/001) No match
 60     [00000000|00000000] (000+000/001) No match
 61     [00000000|00000000] (000+000/001) No match
 62     [00000000|00000000] (000+000/001) No match
 63     [00000000|00000000] (000+000/001) No match
 64     [00000000|00000000] (000+000/001) No match
 65     [00000000|00000000] (000+000/001) No match
 66     [00000000|00000000] (000+000/001) No match
 67     [00000000|00000000] (000+000/001) No match
 68     [a8085b8e|ac846cd4] (013+020/037) Accurately ripped
 69     [c3558d24|c3b05552] (105+105/239) Accurately ripped
 
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-05-18 15:04:23
Different version of the above CD for comparison. Log file also edited for length. Note: Had read errors in the last track so it naturally has No match.
Code: [Select]
[CUETools log; Date: 5/18/2016 6:21:33 AM; Version: 2.1.6]
[CTDB TOCID: y3qHzcML6GUxunmLkD8GswohIa8-] found.
Track | CTDB Status
  1   | (202/204) Accurately ripped
  2   | (198/204) Accurately ripped
  3   | (200/204) Accurately ripped
  4   | (196/204) Accurately ripped, or (4/204) differs in 6 samples @04:09:15
  5   | (199/204) Accurately ripped
  6   | (194/204) Accurately ripped
  7   | (194/204) Accurately ripped
  8   | (195/204) Accurately ripped
  9   | (192/204) Accurately ripped
 10   | (204/204) Accurately ripped
 11   | (204/204) Accurately ripped
 12   | (204/204) Accurately ripped
 13   | (204/204) Accurately ripped
 14   | (204/204) Accurately ripped
 15   | (204/204) Accurately ripped
 16   | (204/204) Accurately ripped
 17   | (204/204) Accurately ripped
 18   | (204/204) Accurately ripped
 19   | (204/204) Accurately ripped
 20   | (204/204) Accurately ripped
 21   | (204/204) Accurately ripped
 22   | (204/204) Accurately ripped
 23   | (204/204) Accurately ripped
 24   | (204/204) Accurately ripped
 25   | (204/204) Accurately ripped
 26   | (204/204) Accurately ripped
 27   | (204/204) Accurately ripped
 28   | (204/204) Accurately ripped
 29   | (204/204) Accurately ripped
 30   | (204/204) Accurately ripped
 31   | (204/204) Accurately ripped
 32   | (204/204) Accurately ripped
 33   | (204/204) Accurately ripped
 34   | (204/204) Accurately ripped
 35   | (204/204) Accurately ripped
 36   | (204/204) Accurately ripped
 37   | (204/204) Accurately ripped
 38   | (204/204) Accurately ripped
 39   | (204/204) Accurately ripped
 40   | (204/204) Accurately ripped
 41   | (204/204) Accurately ripped
 42   | (204/204) Accurately ripped
 43   | (204/204) Accurately ripped
 44   | (204/204) Accurately ripped
 45   | (204/204) Accurately ripped
 46   | (204/204) Accurately ripped
 47   | (204/204) Accurately ripped
 48   | (204/204) Accurately ripped
 49   | (204/204) Accurately ripped
 50   | (204/204) Accurately ripped
 51   | (204/204) Accurately ripped
 52   | (204/204) Accurately ripped
 53   | (204/204) Accurately ripped
 54   | (204/204) Accurately ripped
 55   | (204/204) Accurately ripped
 56   | (204/204) Accurately ripped
 57   | (204/204) Accurately ripped
 58   | (204/204) Accurately ripped
 59   | (204/204) Accurately ripped
 60   | (204/204) Accurately ripped
 61   | (204/204) Accurately ripped
 62   | (204/204) Accurately ripped
 63   | (204/204) Accurately ripped
 64   | (204/204) Accurately ripped
 65   | (204/204) Accurately ripped
 66   | (204/204) Accurately ripped
 67   | (204/204) Accurately ripped
 68   | (204/204) Accurately ripped
 69   | (172/204) Differs in 7035 samples @02:00:16,02:00:35-02:00:36,02:00:55-02:00:56,02:00:74-02:01:00,02:01:19-02:01:20,02:01:39-02:01:40,02:01:58-02:01:59,02:02:03-02:02:04,02:02:23-02:02:24,02:02:42-02:02:43,02:02:62-02:02:63,02:03:07-02:03:08,02:03:26-02:03:27,02:03:46-02:03:47,02:03:66-02:03:67,02:04:10-02:04:11,02:04:30-02:04:31,02:04:50-02:04:51,02:04:69-02:04:70,02:05:14-02:05:15,02:05:34-02:05:35,02:05:53-02:05:54,02:05:73-02:05:74,02:06:18-02:06:19,02:06:37-02:06:38,02:06:57-02:06:58,02:07:21-02:07:22,02:07:41-02:07:42,02:08:45-02:08:46, or (4/204) differs in 7035 samples @02:00:16,02:00:35-02:00:36,02:00:55-02:00:56,02:00:74-02:01:00,02:01:19-02:01:20,02:01:39-02:01:40,02:01:58-02:01:59,02:02:03-02:02:04,02:02:23-02:02:24,02:02:42-02:02:43,02:02:62-02:02:63,02:03:07-02:03:08,02:03:26-02:03:27,02:03:46-02:03:47,02:03:66-02:03:67,02:04:10-02:04:11,02:04:30-02:04:31,02:04:50-02:04:51,02:04:69-02:04:70,02:05:14-02:05:15,02:05:34-02:05:35,02:05:53-02:05:54,02:05:73-02:05:74,02:06:18-02:06:19,02:06:37-02:06:38,02:06:57-02:06:58,02:07:21-02:07:22,02:07:41-02:07:42,02:08:45-02:08:46
[AccurateRip ID: 00ec19db-235aab21-08103745] found.
Track   [  CRC   |   V2   ] Status
 01     [37667aca|aed4aa3d] (022+012/848) Accurately ripped
 02     [531eadc3|3f939eea] (022+013/845) Accurately ripped
 03     [0a63287a|4b20ed3b] (023+013/849) Accurately ripped
 04     [f1bb9db9|aa7f2a57] (021+012/839) Accurately ripped
 05     [5dd8484a|ba24c768] (022+012/837) Accurately ripped
 06     [19bdbb8e|22051284] (021+012/839) Accurately ripped
 07     [1395eb33|68e19bfe] (020+013/822) Accurately ripped
 08     [2d9badd4|024075e0] (022+012/829) Accurately ripped
 09     [0673a775|26ea1976] (020+012/801) Accurately ripped
 10     [00000000|00000000] (000+000/001) No match
 11     [00000000|00000000] (000+000/001) No match
 12     [00000000|00000000] (000+000/000) Silent track
 13     [00000000|00000000] (000+000/000) Silent track
 14     [00000000|00000000] (000+000/000) Silent track
 15     [00000000|00000000] (000+000/000) Silent track
 16     [00000000|00000000] (000+000/000) Silent track
 17     [00000000|00000000] (000+000/000) Silent track
 18     [00000000|00000000] (000+000/000) Silent track
 19     [00000000|00000000] (000+000/000) Silent track
 20     [00000000|00000000] (000+000/000) Silent track
 21     [00000000|00000000] (000+000/000) Silent track
 22     [00000000|00000000] (000+000/000) Silent track
 23     [00000000|00000000] (000+000/000) Silent track
 24     [00000000|00000000] (000+000/000) Silent track
 25     [00000000|00000000] (000+000/000) Silent track
 26     [00000000|00000000] (000+000/000) Silent track
 27     [00000000|00000000] (000+000/000) Silent track
 28     [00000000|00000000] (000+000/000) Silent track
 29     [00000000|00000000] (000+000/000) Silent track
 30     [00000000|00000000] (000+000/000) Silent track
 31     [00000000|00000000] (000+000/000) Silent track
 32     [00000000|00000000] (000+000/000) Silent track
 33     [00000000|00000000] (000+000/000) Silent track
 34     [00000000|00000000] (000+000/000) Silent track
 35     [00000000|00000000] (000+000/000) Silent track
 36     [00000000|00000000] (000+000/000) Silent track
 37     [00000000|00000000] (000+000/000) Silent track
 38     [00000000|00000000] (000+000/000) Silent track
 39     [00000000|00000000] (000+000/000) Silent track
 40     [00000000|00000000] (000+000/000) Silent track
 41     [00000000|00000000] (000+000/000) Silent track
 42     [00000000|00000000] (000+000/000) Silent track
 43     [00000000|00000000] (000+000/000) Silent track
 44     [00000000|00000000] (000+000/000) Silent track
 45     [00000000|00000000] (000+000/000) Silent track
 46     [00000000|00000000] (000+000/000) Silent track
 47     [00000000|00000000] (000+000/000) Silent track
 48     [00000000|00000000] (000+000/000) Silent track
 49     [00000000|00000000] (000+000/000) Silent track
 50     [00000000|00000000] (000+000/000) Silent track
 51     [00000000|00000000] (000+000/000) Silent track
 52     [00000000|00000000] (000+000/000) Silent track
 53     [00000000|00000000] (000+000/000) Silent track
 54     [00000000|00000000] (000+000/000) Silent track
 55     [00000000|00000000] (000+000/000) Silent track
 56     [00000000|00000000] (000+000/000) Silent track
 57     [00000000|00000000] (000+000/000) Silent track
 58     [00000000|00000000] (000+000/000) Silent track
 59     [00000000|00000000] (000+000/000) Silent track
 60     [00000000|00000000] (000+000/000) Silent track
 61     [00000000|00000000] (000+000/000) Silent track
 62     [00000000|00000000] (000+000/000) Silent track
 63     [00000000|00000000] (000+000/000) Silent track
 64     [00000000|00000000] (000+000/000) Silent track
 65     [00000000|00000000] (000+000/000) Silent track
 66     [00000000|00000000] (000+000/000) Silent track
 67     [00000000|00000000] (000+000/000) Silent track
 68     [00000000|00000000] (000+000/000) Silent track
 69     [abdb91db|38dc7670] (000+000/724) No match
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-05-18 20:30:23
I think it's the second time that I encounter this issue. If I recall correctly I had the same issue with a Marilyn Manson CD (Edit: just checked it's on Marilyn Manson - 1996 - Antichrist Superstar), the difference between yours and mine lies in (000+000/001) Vs. (000+000/000) ... seems like CUETools tries to compare silence against some garbage in the database ... maybe it would be easier to report as "Silent track" in log & "Rip Accurate" in batch as soon as the CRC are [00000000|00000000] no matter what's in the database (providing the other real tracks are OK indeed).
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-06-02 02:10:03
Request: It would be nice & save me some time if in the "input/folder browser/By AccurateRip Confidence" tree view, Cuetools would automatically sorts rips between: on one hand, rips that are not in the AR database at all, and on the other hand, rips that are not accurate. As of now, both are mixed in the Confidence 0 category, so it's a mess & I have to check manually.

Edit: The addition of "not accurate+differs" category would be nice too, in order to detect, in a blink of an eye, rips that you can potentially repair.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-21 20:54:37
Hey.

I've just wondered,... how can one find out the ID of one's system that is used for CTDB?
I'd assume there has to be something in order to identify a submitter in order to prevent multiple submissions, just like AccurateRip has its ID and it would be handy to know this ID should one need to reinstall the system or so.

Cheers,
Chris.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-06-21 21:59:30
If i recall correctly, it's just a hash of some windows system IDs that are based on motherboard serial number i think. Unfortunately you cannot change it.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-21 22:14:28
Aren't you upstream?! It should be possible to set any ID one likes in the respective client, regardles of whatwindows does and says…

At least it would be a bad idea, that the ID changes, just because of .eg. a new mainboard,...that would IMHO also kinda spoil the DB with wrong data, if people re-rip the same CDs but just on different hardware.

Cheers.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-21 22:18:49
btw, while I don't know the exact implementation,... using some system serial numbers or CPUID, instead of e.g. a randomly generated UUID, may be quite harmful as well,… consider e.g. if people would run their ripper from a VM, and those serial numbers would be the same there…
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-06-22 00:14:48
It's not that critical that those be unique. It's also not that critical that those don't change for a person. A dedicated enough person can always inject a little garbage into database, but that's not likely to happen and not likely to affect much. So, the way i see it, hash of windows system/motherboard id is good enough for the purpose of blocking accidental multiple submissions from the same user.

I debated introducing actual user accounts, but thought better of it.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2016-06-22 04:20:19
It's an old argument that has been long settled.

Multiple submissions of the same bad data are inconsequential when good data exists while you're checking the rips of your own legally distributed physical media.  Instances where the bad data comes from a faulty pressing (which are quite plentiful) cannot be helped by making user IDs more tamper-proof.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-22 13:55:27
Well my point here was rather that prefectionsists that rip their CDs multiple times (e.g. with different programs, EAC,CUERipper,...) may get more easily wrong confidence values, which doesn't matter for CDs with very high submissions, but does for such which are very very rare and where one is e.g. the only submitter.

In fact I've noticed that different programs (eac, plextools, dbpoweramp, cuetools) find different errors in some special cases,...

CTBD (or at least the EAC plugin) seems to have the additional problem, that it submits the same results at least twice (on the same hardware):
When I first rip in image mode (without C2-error detection) I get a submission, when I then rip in tracks mode, I get a further one per track... when I then rip again in image mit (with C2) I don't get another one.
AccurateRip doesn't seem to have that problem.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-22 13:57:13

Oh and another issue I've noticed:
All these programs seem to be pretty unreliable in determining ISRC and CATALOGUE.
I have ripped some 800 CDs now, Plextools and EAC give ISRC/CATALOGUE in the cue files for roughly ~360, but they already differ (i.e. for some CDs Plextools finds ISRC/CATALOGUE, where EAC doesn't… for a few cases less it's vice-versa).
CUERipper performs worst, it finds ISRC/CATALOGUE only for some ~50 CDs.
Interestingly I even had cases, where it did found both and on a later re-rip it no longer found them.

All the same hardware, Plextor PX-760A ripper…
Any ideas?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-06-22 14:12:47
CTBD (or at least the EAC plugin) seems to have the additional problem, that it submits the same results at least twice (on the same hardware):
When I first rip in image mode (without C2-error detection) I get a submission, when I then rip in tracks mode, I get a further one per track... when I then rip again in image mit (with C2) I don't get another one.
Please provide log files.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-26 00:42:12
CTBD (or at least the EAC plugin) seems to have the additional problem, that it submits the same results at least twice (on the same hardware):
When I first rip in image mode (without C2-error detection) I get a submission, when I then rip in tracks mode, I get a further one per track... when I then rip again in image mit (with C2) I don't get another one.
Please provide log files.

Attached are the logfiles/CUE/etc. from the rip of the Back To The Future 3, Varese Sarabande Edition, Disc 2 in question.

*.old.* is a rip made November 2015
*.new.* is a rip made today
All CUETools version 2.1.6, same drive (Plextor PX760) and other hardware.
The only difference is, that I've upgraded from Windows 8.1 to 10 in the meantime (including other windows updates).

You'll notice that everything is effectively the same, except the missing CATALOGUE, ISRC and additional INDEX 00 from the CUE file.

Any ideas?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-26 00:49:20
And another issue (same hardware, versions as right above):

This happens with on CD only (which rips fine in EAC and plextools), it's the Elisabeth 10th Anniversary Concert, ripping with Paranoid and Test&Copy.

Test mode rips "fine", i.e. it continues with the copy run,... but at the very end of it (presumably exactly at the end), I get the error as shown on the screenshot.
The only written file (i.e. not auto-deleted-by-cueripper) is the also attached CUE file. Also attached are the CUE files for that CD as generated by plextools and EAC.

Notice the different DISCIDs, EAC and CUERipper detect (plextools doesn't store that at all).
And of course also the "INDEX 01 954437:10:45" which CUERipper "detects" and is obviously bogus.

Any ideas here?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-06-26 01:11:16
Update: oops, sorry, found the duplicate submission. It was from before, Novermber the 10th 2015. Yeah, you are right, that's weird.

Code: [Select]
ctdb=> select * from submissions where userid = 'kdSFOVwG5dQl3KIWovI_qfAJZBY-' and entryid=3241650;
  subid  | entryid |            userid            |                                              agent                                              |        time        |      ip      |        drivename        | barcode | quality
----------+---------+------------------------------+-------------------------------------------------------------------------------------------------+---------------------+----------------+---------------------------+---------+---------
 12202098 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - DVDR  PX-708A) | 2015-12-20 15:00:29 | xx.xxx.xxx.241 | PLEXTOR  - DVDR  PX-708A |        |    100
 11430957 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - CD-R  PREMIUM) | 2015-11-10 18:04:07 | xx.xxx.xxx.239 | PLEXTOR  - CD-R  PREMIUM |        |    100
(2 rows)


So the reason it accepted the second submission is that the drive name has changed.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-06-26 01:15:30
I actually wanted to see logs showing the EAC plugin submitting twice (https://hydrogenaud.io/index.php/topic,66233.msg924275.html#msg924275).

Your missing CATALOGUE, ISRC and additional INDEX 00 from the CUE file
http://www.cuetools.net/wiki/CUERipper_Options
Do you have Detect Indexes set to False?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-26 02:01:29
So the reason it accepted the second submission is that the drive name has changed.
Ah,.. well I didn't actually mean that, though it's also questionable whether this should happen or not.
I really have no strong opinion towards yes or no,... using a different drive may give different "info" and thus confidentiality, OTOH using the same medium and counting up the numbers is probably bad.

This of course doesn't matter for CDs whit many submissions from different users,... but if there's only one or two entries, perhaps from the same guy then, confidentiality get's quite low, even though the numbers are "high".


I actually wanted to see logs showing the EAC plugin submitting twice (https://hydrogenaud.io/index.php/topic,66233.msg924275.html#msg924275).
Sorry, I haven't read closely enough.
And I must apologise myself,... as I've had described the problem wrongly...
The problem isn't double submission, but rather that it CTDB implementations seem to count my own submission as confidence, which is IMHO quite bad.
Imagine I scan a very rare CD (and I have a few of those ;) )... there may be 0 or perhaps 1 submissions from other people.
I do the first rip, it gets submitted... and following that (in further rips) I'll already have a confidence of 1 (even though it's just my own which may be wrong).
Worse, when there was already one, and that differed from mine, I'll then still get a confidence of 1 (with one differing).
Even if I then clean the CD or so, and would get the other guy's result, I couldn't easily tell anymore whether I have now mine or his.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-26 02:03:00
But as I've just greped through all my logs, I noticed the following:
Every 1st time I rip a CD, the following lines appear:
>Submit result: VNthXYlxsQjeoXX1Qk7C1us7JF8- has been uploaded
I'd assume lines like these are, when I'm the first one submitting this CD, right?

>Submit result: Vlgp9wXAHMFYlROkdp89y5BtuQc- has been confirmed
I'd assume "confirm" is actually submit (my result) and it matched already submitted results, right?

There are a few like these
>Submit result: 3.mlBuCaBRtWb8JiBFXgryK1upQ- has been confirmed, 3.mlBuCaBRtWb8JiBFXgryK1upQ- has been confirmed
>Submit result: ny2wN9e1DSAA_c3wuEbkSeWY7_k- has been confirmed, ny2wN9e1DSAA_c3wuEbkSeWY7_k- has been confirmed
>Submit result: vmFQ.yhg.oBoKe.XSEuPA9l7xwk- has been confirmed, vmFQ.yhg.oBoKe.XSEuPA9l7xwk- has been confirmed
Why writing it twice?

a few:
>Submit result: already submitted
>Submit result: already submitted, already submitted
appear as well, but I cannot tell anymore, whether my data on whether this was the 1st rip is just bogus.

Every 2nd time I rip a CD, the following lines appear:
>Submit result: already submitted
>Submit result: already submitted, already submitted

Any ideas?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-26 02:07:07
Code: [Select]
 12202098 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - DVDR  PX-708A) | 2015-12-20 15:00:29 | xx.xxx.xxx.241 | PLEXTOR  - DVDR  PX-708A |        |    100
 11430957 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - CD-R  PREMIUM) | 2015-11-10 18:04:07 | xx.xxx.xxx.239 | PLEXTOR  - CD-R  PREMIUM |        |    100
(2 rows)

btw: That one is not from myself, though I likely generated a few of these… I always have either PX760-A and in few cases there may be an additional Plextor Premium.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-06-26 04:54:54
Oops. I thought this was the one because it's the only one that matched the date from the log (Dec 20). So it had to be this one then - and there's only one:
Code: [Select]
ctdb=> select * from submissions where userid = '1utddNLiRo8.nJYL3jttLDFJ4fE-' and entryid=3241650;
  subid  | entryid |            userid            |                                      agent                                        |        time        |      ip      |        drivename        | barcode | quality
----------+---------+------------------------------+------------------------------------------------------------------------------------+---------------------+---------------+---------------------------+---------+---------
 11713428 | 3241650 | 1utddNLiRo8.nJYL3jttLDFJ4fE- | EACv1.0b6 CTDB 2.1.6 (Microsoft Windows NT 6.2.9200.0) (PLEXTOR  - DVDR  PX-760A) | 2015-11-26 05:56:47 | xx.xxx.xxx.99 | PLEXTOR  - DVDR  PX-760A |        |    100
The rest were denied:
Code: [Select]
ctdb=> select time,ip,drivename,barcode,quality,reason from failed_submissions where userid = '1utddNLiRo8.nJYL3jttLDFJ4fE-' and barcode='0030206115987';
        time         |      ip       |         drivename         |    barcode    | quality |      reason
---------------------+---------------+---------------------------+---------------+---------+-------------------
 2015-12-20 03:21:26 | xx.xxx.xxx.99 | PLEXTOR  - DVDR   PX-760A | 0030206115987 |     100 | already submitted
 2015-12-20 03:39:26 | xx.xxx.xxx.99 | PLEXTOR  - DVDR   PX-760A | 0030206115987 |     100 | already submitted
This only shows the ones where barcode (CATALOG) was read correctly. There are plenty more.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-26 05:21:02
Your missing CATALOGUE, ISRC and additional INDEX 00 from the CUE file
http://www.cuetools.net/wiki/CUERipper_Options
Do you have Detect Indexes set to False?
Forgot to answer that:
No, DetectGaps=1 in settings.txt. So that should be True.

Code: [Select]
 11713428 | 3241650 | 1utddNLiRo8.nJYL3jttLDFJ4fE- | EACv1.0b6 CTDB 2.1.6 (Microsoft Windows NT 6.2.9200.0) (PLEXTOR  - DVDR  PX-760A) | 2015-11-26 05:56:47 | xx.xxx.xxx.99 | PLEXTOR  - DVDR  PX-760A |        |    100
Given on the IP address you've had there before the edit, I'd say that's me… so this is my UID then!?

The rest were denied:
As I wrote above, I just wrongly described the problem... it's not multiple times submitted, but the plugin shows me my own submission as confidence=1, while I think my own shouldn't count (as it's e.g. the case with AccurateRip).


This only shows the ones where barcode (CATALOG) was read correctly. There are plenty more.
What exactly do you mean here? Aren't submissions made when CATALOG is not read correctly?

btw: have you seen the other issues I've described above?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-06-26 05:30:44
It's hard to reliably say that a particular submission was yours. I'd rather not have people rely on database being able to detect that - too many ways this can be misleading. In the end, confidence only matters when it's "large enough" and your one or two submissions are not significant then.

CATALOG is not very relevant here. Yes, submissions are made whether or not CATALOG is read. It's just an artefact of how failed_submissions table works that this was the only way i could figure out which ones relate to this particular CD - i don't store discid in the failed_submissions table, perhaps a mistake.

I'm too sleepy to reply to the rest at the moment ;)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-27 02:12:04
It's hard to reliably say that a particular submission was yours. I'd rather not have people rely on database being able to detect that
Shouldn't that be rather simple? Either based on the submitting user's ID (as e.g. Accurate Rip does it),... or at least by storing the discIDs of ripped discs locally and not counting those that have been submitted before?

- too many ways this can be misleading. In the end, confidence only matters when it's "large enough" and your one or two submissions are not significant then.
Well I wouldn't necessarily say that,… if confidence is only 1, but that is from another person, than it's still pretty likely that one's version is correct... simply because it's rather unlikely that both have had errors in the very same places.

And for rare CDs you often don't get more than a confidence of 1 or 2 - it would be nice if this use case is covered as well, which would IMHO be easy, by simply not counting one's own submissions.


CATALOG is not very relevant here. Yes, submissions are made whether or not CATALOG is read. It's just an artefact of how failed_submissions table works that this was the only way i could figure out which ones relate to this particular CD - i don't store discid in the failed_submissions table, perhaps a mistake.
Ah I see :)

I'm too sleepy to reply to the rest at the moment ;)
Already looked at the other issues? Well as soon as you do, just tell me if you need more information.

Cheers,
Chris
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2016-06-27 03:14:34
Shouldn't that be rather simple? Either based on the submitting user's ID (as e.g. Accurate Rip does it),... or at least by storing the discIDs of ripped discs locally and not counting those that have been submitted before?
Didn't you say that you were concerned because you made submissions of the same disc but with different operating systems, or did I miss something?

simply because it's rather unlikely that both have had errors in the very same places.
Not necessarily.  Due to physical damage, yes but this is only one potential reason for errors; buggy hardware and/or software can be the source errors, among other things; and these errors can be consistent.

This is not to say there is no possible way for improvement, just that there will always be edge cases.

Tell me, honestly, have you heard any problems with the extractions in question?  Have you looked for any signs of erroneous data with a competent wave editor?  ...or is this just wanking your OCD?

I'm sorry if this sounds harsh or you think I'm being a troll, but I went down this road over a decade ago.  Thankfully, I got over it.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2016-06-27 03:33:16
Post script:
If you are that concerned about these uncommon titles, you could always purchase a second physical copy and extract it with different hardware, or attempt to obtain a digital copy through other means.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-06-27 07:43:16
Another small request: at some point, please move the create .toc option to the main window of the GUI, make it a tick box there. Personally, I use .toc to store the datatrack length instead of new EAC logs with included TOC for the very good reason that most of the rips of my own collection pre-date the EAC era with TOC in logs. So when accuraterip tells me that a CD which was not found may have an extra-track, I enter the suggested length manually & create a .toc while I check it with the extra-track, so that Cuetools will automatically find the extra-track length in the .toc next time I check it. The option is more important than what it first seemed, especially as enhanced CD are very frequent, having it somewhere in the main window would be handy ;)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-06-27 17:26:38
Didn't you say that you were concerned because you made submissions of the same disc but with different operating systems, or did I miss something?
No that was another issue, i.e. when one changes the computer or reinstalls windows and gets a new ID,… actually I had this already once with AccurateRip...
The question there is, how could one manually set his own old ID.

Of course, this is somehow related to the issue of counting one's own submissions towards confidence in the case of very rare CDs.

Not necessarily.  Due to physical damage, yes but this is only one potential reason for errors; buggy hardware and/or software can be the source errors, among other things; and these errors can be consistent.
This is not to say there is no possible way for improvement, just that there will always be edge cases.
Even in the case of buggy hardware (unless it's a firmware bug, i.e. always fails under the same conditions, which isn't necessarily the case for FW bugs either), it's pretty likely that the error may pop up in another block.
So sure, errors may be consistent, but it would be still better to catch those cases where they aren't.

Tell me, honestly, have you heard any problems with the extractions in question?  Have you looked for any signs of erroneous data with a competent wave editor?  ...or is this just wanking your OCD?

I'm sorry if this sounds harsh or you think I'm being a troll, but I went down this road over a decade ago.  Thankfully, I got over it.
Well I think we've had that very same discussion a while ago over in the EAC forum, hadn't we?
My answers are basically the same as back then, different software, even different extraction modes produced different results, inculding errors which one software found and the other node.
I recently found a bug in EAC, which leads to all tracks <7s or so to have wrong AccurateRip checksum calculated (Andre finally found the cause in his code, but I think it's not yet fixed in the most recent version).
This for example didn't change the actual raw PCM, but I also had cases where on both rippers didn't notice errors, but produced different files and one could clearly hear some distortion.

Apart from that, if I'd wish to "waste" my time by "wanking" my CD's… wouldn't that be up to me?!


Post script:
If you are that concerned about these uncommon titles, you could always purchase a second physical copy and extract it with different hardware, or attempt to obtain a digital copy through other means.
Well, the thing about such extremely rare CDs is typically that they're extremely rare  ::) … and even if multiple copies would be available to buy (which generally isn't the case), they cost a hell of a fortune…
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 2016-06-27 17:45:41
The question there is, how could one manually set his own old ID.
...then follows the concern about intentional multiple submissions (bad data or otherwise).

it's pretty likely that the error may pop up in another block.
...or not.

Well I think we've had that very same discussion a while ago over in the EAC forum, hadn't we?
I recall you made a lot of claims without any hard evidence and were not open to configuration suggestions.

Apart from that, if I'd wish to "waste" my time by "wanking" my CD's… wouldn't that be up to me?!
OCD and I never used the word waste.  How you choose to spend your time is indeed your business.  I wouldn't expect too much of other people's time, though. ;)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-07-02 17:10:47
@Gregory:
Anything new about the other issues I've described above?

Is there a public bugtracker where one could properly record these?

Any there's another one (at least in 2.1.6):
While CUERipper seems to properly store the SecureMode=<n> setting on exit, it doesn't seem to reload it on start, at least not when the value was 2/Paranoid.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-07-03 17:11:22
The link to the bug tracker page can be found on the CUETools wiki (http://www.cuetools.net/wiki/Main_Page).

CUERipper does not start in Paranoid mode (known issue (https://hydrogenaud.io/index.php/topic,66233.msg779149.html#msg779149) - see end of post).

Note: You seem to think (unless I misread) that AccurateRip somehow prevents you from verifying against your own rip. You might not be able to verify against your own rip in AccurateRip immediately but that doesn't mean it won't show up for you to verify against in time. (one reference (https://forum.dbpoweramp.com/showthread.php?36456-How-much-it-takes-to-upload-CD-info-to-accuraterip&s=84ecc6d928d972db74699aaeeae392a6&p=158764&viewfull=1#post158764) - posted by the developer.)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cálestyo on 2016-07-03 20:54:22
Note: You seem to think (unless I misread) that AccurateRip somehow prevents you from verifying against your own rip. You might not be able to verify against your own rip in AccurateRip immediately but that doesn't mean it won't show up for you to verify against in time. (one reference (https://forum.dbpoweramp.com/showthread.php?36456-How-much-it-takes-to-upload-CD-info-to-accuraterip&s=84ecc6d928d972db74699aaeeae392a6&p=158764&viewfull=1#post158764) - posted by the developer.)

Hmm perhaps Spoon meant after the AR ID has changed?
At least so far I never found AR to count up my own submission to the confidence and I did in fact re-rip quite a number of CDs a year or so later after the first submission.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-07-03 22:40:22
https://hydrogenaud.io/index.php/topic,53150.msg476266.html#msg476266
https://hydrogenaud.io/index.php/topic,98704.msg819699.html#msg819699
https://forum.dbpoweramp.com/showthread.php?19914-Discs-disappearing-from-the-AccurateRip-DB&p=94155&viewfull=1#post94155
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2016-07-04 10:25:33
At least so far I never found AR to count up my own submission to the confidence and I did in fact re-rip quite a number of CDs a year or so later after the first submission.

If you used dBpoweramp on the same computer, AccurateRip will know; getting and submitting an identical result will not increase the confidence.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jgebis on 2016-07-15 21:02:02
I searched, and couldn't find anything on this -- is there any chance we could get the ability to use a proxy with the EAC CUETools plugin?  (Or am I missing something, and is that already possible?)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-07-17 17:10:27
Feature request: Two minor options that I'd like to have:

1- Force pregap 00:00:00, as actually you can enter any pregap except 00:00:00, it's not very usefull but sometime I have a non-accurate rip with a non-00:00:00 pregap & a high CTDB confidence and CTDB telling me that a pressing with pregap 00:00:00 exists ... in that special case I'd like to be able to overwrite the pregap in the CUE without editing it manually, in order to simply check the confidence with PG 00:00:00.

2: Force to test without CD-Extra Data even if there is a bonus track length in the CTDB database which is automatically added, as most of the time, the automatically added length is correct, but not always.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-07-20 17:33:06
Yesterday I was surprised, I thought Cuetools was able to verify pressings with different offset automatically and I realized it was not always the case.

Before fixing the offset manually: (Not accurate)

Code: [Select]
[CUETools log; Date: 20/07/2016 06:01:28; Version: 2.1.6]
[CTDB TOCID: FJE5bHuttMI.k7ZJG_ShMtRgoNo-] found.
        [ CTDBID ] Status
        [4960160e] (16/16) Accurately ripped
Track | CTDB Status
  1   | (16/16) Accurately ripped
  2   | (16/16) Accurately ripped
  3   | (16/16) Accurately ripped
  4   | (16/16) Accurately ripped
  5   | (16/16) Accurately ripped
  6   | (16/16) Accurately ripped
  7   | (16/16) Accurately ripped
  8   | (16/16) Accurately ripped
  9   | (16/16) Accurately ripped
 10   | (16/16) Accurately ripped
 11   | (16/16) Accurately ripped
 12   | (16/16) Accurately ripped
 13   | (16/16) Accurately ripped
 14   | (16/16) Accurately ripped
 15   | (16/16) Accurately ripped
 16   | (16/16) Accurately ripped
 17   | (16/16) Accurately ripped
[AccurateRip ID: 0025e3fc-01ebb30d-e70fa511] found.
Track   [  CRC   |   V2   ] Status
 01     [1119c2ae|5c8a5a62] (0+0/4) No match
 02     [4a4667c4|489a7912] (0+0/4) No match
 03     [17f79a3c|e7085aa5] (0+0/4) No match
 04     [bba8b337|91d1d4b8] (0+0/4) No match
 05     [20c25d31|6ccba031] (0+0/4) No match
 06     [900ca1dc|f061f75d] (0+0/4) No match
 07     [1473cf38|d62bb70b] (0+0/4) No match
 08     [155dac0e|de8857f3] (0+0/4) No match
 09     [4dc0b8f8|f7e792ee] (0+0/4) No match
 10     [5c3bda5f|8412677b] (0+0/4) No match
 11     [96f35c77|f7ef8664] (0+0/4) No match
 12     [ae06e6ba|71d5f14c] (0+0/4) No match
 13     [73db24ce|69fd7ede] (0+0/4) No match
 14     [f37febc9|3ca717d3] (0+0/4) No match
 15     [fb719bd0|b05afe4d] (0+0/4) No match
 16     [1d5413c7|33b843f6] (0+0/4) No match
 17     [71e6694d|b31d295f] (0+0/4) No match
Offsetted by 667:
 01     [f4b37882] (0/4) No match (V2 was not tested)
 02     [19bfc8ac] (0/4) No match (V2 was not tested)
 03     [18482812] (0/4) No match (V2 was not tested)
 04     [0ba29c5e] (0/4) No match (V2 was not tested)
 05     [f78bf496] (0/4) No match (V2 was not tested)
 06     [4dfdfe3c] (0/4) No match (V2 was not tested)
 07     [d3b8b914] (0/4) No match (V2 was not tested)
 08     [f4de77f4] (0/4) No match (V2 was not tested)
 09     [0d5abad6] (0/4) No match (V2 was not tested)
 10     [b0e8e9d5] (0/4) No match (V2 was not tested)
 11     [3f125ab3] (0/4) No match (V2 was not tested)
 12     [5882633b] (0/4) No match (V2 was not tested)
 13     [e2fdca3b] (0/4) No match (V2 was not tested)
 14     [60b05e38] (0/4) No match (V2 was not tested)
 15     [9cc72543] (0/4) No match (V2 was not tested)
 16     [dcac27da] (0/4) No match (V2 was not tested)
 17     [1bc80690] (0/4) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [D790BC83] [EBD10AB9]          
 01   98,8 [5A304890] [9D1CDDFA]          
 02   98,8 [ABED67C9] [8BBEE65F]          
 03   98,8 [EC11C3D8] [E0D4AD23]          
 04   98,8 [664C7EB4] [8A64C043]          
 05   98,8 [37A9D3D9] [103B3090]          
 06   98,8 [DFE5262B] [378BDFF5]          
 07   98,8 [E0765CC3] [E3921E80]          
 08   98,8 [04E4EE5C] [FB09F0D8]          
 09   98,7 [1BB4C16E] [11BBBF09]          
 10   98,8 [FCDFB00E] [44299CCA]          
 11   98,8 [08892148] [C0E24480]          
 12   98,8 [F88319F3] [52C69A3A]          
 13  100,0 [3A3F14EE] [0B3EB7DE]          
 14   98,8 [1274678F] [98350307]          
 15   98,8 [FED211D7] [EE3F9CB0]          
 16   98,8 [CE3261CA] [0D3C74B2]          
 17   98,8 [FA20A189] [97703284]          

After fixing the offset manually (Accurate) :

Code: [Select]
[CUETools log; Date: 20/07/2016 18:18:46; Version: 2.1.6]
Offset applied: 667
[CTDB TOCID: FJE5bHuttMI.k7ZJG_ShMtRgoNo-] found.
        [ CTDBID ] Status
        [4960160e] (16/16) Accurately ripped
Track | CTDB Status
  1   | (16/16) Accurately ripped
  2   | (16/16) Accurately ripped
  3   | (16/16) Accurately ripped
  4   | (16/16) Accurately ripped
  5   | (16/16) Accurately ripped
  6   | (16/16) Accurately ripped
  7   | (16/16) Accurately ripped
  8   | (16/16) Accurately ripped
  9   | (16/16) Accurately ripped
 10   | (16/16) Accurately ripped
 11   | (16/16) Accurately ripped
 12   | (16/16) Accurately ripped
 13   | (16/16) Accurately ripped
 14   | (16/16) Accurately ripped
 15   | (16/16) Accurately ripped
 16   | (16/16) Accurately ripped
 17   | (16/16) Accurately ripped
[AccurateRip ID: 0025e3fc-01ebb30d-e70fa511] found.
Track   [  CRC   |   V2   ] Status
 01     [f4b37882|33435413] (0+4/4) Accurately ripped
 02     [19bfc8ac|0984b049] (0+4/4) Accurately ripped
 03     [18482812|d44093d6] (0+4/4) Accurately ripped
 04     [0ba29c5e|ec114523] (0+4/4) Accurately ripped
 05     [f78bf496|3d6ed076] (0+4/4) Accurately ripped
 06     [4dfdfe3c|5be027bd] (0+4/4) Accurately ripped
 07     [d3b8b914|86942f6e] (0+4/4) Accurately ripped
 08     [f4de77f4|b7fae96d] (0+4/4) Accurately ripped
 09     [0d5abad6|8db9a53e] (0+4/4) Accurately ripped
 10     [b0e8e9d5|1a74c90a] (0+4/4) Accurately ripped
 11     [3f125ab3|9fc472ac] (0+4/4) Accurately ripped
 12     [5882633b|1868d81b] (0+4/4) Accurately ripped
 13     [e2fdca3b|d5ddf15d] (0+4/4) Accurately ripped
 14     [60b05e38|a061772e] (0+4/4) Accurately ripped
 15     [9cc72543|75bc2576] (0+4/4) Accurately ripped
 16     [dcac27da|f788f3ef] (0+4/4) Accurately ripped
 17     [1bc80690|3ad45fbd] (0+4/4) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100,0 [3DAFCCF6] [EBD10AB9]          
 01   98,8 [47F69EA5] [7D6BB354]          
 02   98,8 [3AFEB0FE] [E8C695D5]          
 03   98,8 [2E3FFF18] [1DA7215B]          
 04   98,8 [A88A6210] [DEC72C5E]          
 05   98,8 [8499EDB3] [5D786BAE]          
 06   98,8 [E793291F] [B260FA5B]          
 07   98,8 [E2444CD0] [EABB0EE8]          
 08   98,8 [D0E24621] [45EEBC97]          
 09   98,7 [B4685EED] [55DB28CE]          
 10   98,8 [81A5A9D4] [01E48252]          
 11   98,8 [422329BF] [72E0357E]          
 12   98,8 [59BA900F] [F3F3368B]          
 13  100,0 [3D90862C] [E4340417]          
 14   98,8 [83F3F19B] [68D4FCF6]          
 15   98,8 [B0AD8226] [C05CF207]          
 16   98,8 [AA15B1DE] [2E26F637]          
 17   98,8 [9C74A495] [92DE76A7]

Is this normal ? I thought Cuetools was able to check a rip with a bad offset automatically ... Is it just me who was wrong assuming Cuetools could do it ? I was kinda shocked as I may have deleted a bunch of perfectly valid rips due to my assumption ...

Quote from Cuetools Wiki:
Quote
The unique feature of CUETools AccurateRip verification is offset detection. A rip that was made without offset correction can still be verified against the database; the offset can be found and corrected.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-07-20 18:34:26
AccurateRip V2 CRC is fundamentally broken... It was supposed to be better than V1 in avoiding collisions (it is not), but instead it lost the symmetry that allowed V1 to be offset-corrected. A choice of a well-designed CRC like CRC32 would solve both problems, unfortunately that path wasn't taken. Which was part of the reason why CTDB now has per-track CRCs.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-07-20 19:18:41
OK thks for the quick answer ... this is getting really tricky. Let me summarize what I think I understund so far, plz correct me if I assume anything wrong.

- Accuraterip V2 is a correct CRC for corruption verification but is broken for offset detection, right ? (I assume that because otherwise I guess you would have completely removed it, no ?)

quote from Cuetools Wiki on V2

Quote
No match (V2 was not tested) NEW in 2.1.4
    Track starts at correct position (for that offset) but CRC doesn't match, possible ARv2 CRC matches

(ARv2 is only tested at zero offset)

So in my case/exemple above, the rip after offset correction is accurate, right ?

Now this leads me to 2 questions:

- How is it possible that accuraterip CRC V2 would be a 100% match & accuraterip CRC V1 would be a 0% match ? (unless V2 is completely broken for corruption check too, cf. the case above)

- I just checked a couple of recent 2016 releases to compare V1 vs. V2 confidence, it seems most of them rely on V2, so am I right to assume that, as of now, Accuraterip somehow relies on V1 to find the offset & on V2 to check the CRC, right ?

If all the above is not completely wrong, then why CRC V2 is not tested outside of offset 0 ? Then my rip would have been accurate from the begining & this discussion would not have occured.

There must be something I don't get here because either V2 is completely wrong (both for offset & check) & it should be removed ... or it is at least OK for verification & then it should be used by default (even outside of offset zero) ... finally, if V2 is ok for verification how can it be that both disagree (cf. case above) ... I mean if I compare with .sfv & .md5 checksums, if I have both a .sfv & a .md5 of the same set of files & the md5 checksum says it's ok, then the probability that the .sfv says the files are OK too is very high ... the way I see it, it should be similar with Accuraterip V1 & V2.

I must be missing something somewhere. Again thks for trying to explain ;)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-07-20 19:32:27
Accuraterip V2 is about as good for corruption verification as V1. It's flawed, but definitely good enough.
And yeah, it's broken for non-offset corrected verification. E.g. you have to recalculate it from scratch for every offset that you want to verify, unlike symmetrical CRCs such as AR V1/CRC32 that allow you to "offset-correct" a CRC without re-processing the whole data.

Quote
So in my case/exemple above, the rip after offset correction is accurate, right ?
Yes.

Quote
- How is it possible that accuraterip CRC V2 would be a 100% match & accuraterip CRC V1 would be a 0% match (unless V2 is completely broken for corruption check too, cf. the case above)
No match doesn't mean that it's corrupted - it just means that there were no matches, e.g. no submissions in the database with CRC that equals V1 CRC of your tracks. I assume this is a new CD and nobody ever copied it using old AccurateRip software that produces V1 CRCs.

Quote
- I just checked a couple of recent 2016 releases to compare V1 vs. V2 confidence, it seems most of them rely on V2, so am I right to assume that, as of now, Accuraterip somehow relies on V1 to find the offset & on V2 to check the CRC.
Yes. For each track, AccurateRip returns keeps pairs of CRCs - one for offset detection (which is a CRC of a short fragment of a track), and one actual CRC for the whole track. Surprisingly, the first one is always V1.

Quote
If all the above is not completely wrong, then why CRC V2 is not tested outside of offset 0 ? Then my rip would have been accurate from the begining & this discussion would not have occured.
Because it would take at least twice the time to do verification - once to find offsets, and then potentially many times to calculate CRCs with offsets found in step one.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-07-20 20:09:28
Thanks a lot for the clarification ;) I "more or less" knew all that, especially as I read most of this thread, yet I didn't realize its implication on rips tagged as "V2 was not tested" ... from now on, I will take special care of those ... damned, I think I deleted a whole lot of perfect rips over the years ;(
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: SF01 on 2016-07-27 20:54:51
FLACCL: hi-res audio support refers to the CUETools.FLACCL.cmd.exe command-line tool.

CUETools.exe still only accepts PCM (or lossless) Red Book audio input. You will still receive an "Exception: Audio format is not Red Book PCM" in CUETools if you try to input other than 16-bit, 44.1kHz stereo.


Any chance to remove this limitation in an update?

It would be really nice to be able to use CT for images od DTS-CDs, or audio rips from DVDs and BDs in format of one file + cue to split to tracks.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2016-07-27 23:33:14

Any chance to remove this limitation in an update?

It would be really nice to be able to use CT for images od DTS-CDs, or audio rips from DVDs and BDs in format of one file + cue to split to tracks.

It would be gr8 if that limitation could be removed.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-07-28 02:28:29
This limitation was actually useful to me more than once, so if ever you remove it plz make it optional, so that you're still warned that you're processing 24bit or mono files without having to check.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Faqew on 2016-08-23 18:11:46
Hi there,

I'm using CUETools for two or three years now and I'm very happy with it. But some months ago I started to run into some problems with the ripper and I don't know why.
It doesn't load/find most of my recently bought CDs although they are present in the MusicBrainz database (I even submitted most of them on my own to MusicBrainz). Clicking "refresh" doesn't change a thing but when I click on the MusicBrainz logo in the right lower corner the CD is found at once in the MusicBrainz database in my browser. So the information IS in the MusicBrainz database, my CUERipper somehow just fails to find and catch it there.

My system:
i7 2600K (not overclocked)
GTX 970
8GB RAM
LG CH10LS20 with firmware 1.02
Windows 10 64bit updated from Windows 7 64bit

What I already tried:

- lots of googeling hoping to find the answer
- CUETools versions 2.1.4. to 2.1.6. with deleted custom settings/default settings
- changing CTDB server in the options to freedb.musicbrainz.org, http://freedb.musicbrainz.org:80/~cddb/cddb.cgi and freedb.freedb.org
- most of my CDs which have been found in the database by CUERipper before

Any ideas on how to solve my problem? CUERipper really is my favorite CD ripper and I don't want to have to look for another program. :-/
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2016-08-23 18:22:19
MusicBrainz updates its schema and replication software from time to time, and every time it does, i need to do some changes on the server to make it update again. They did it again around May i think, but i somehow missed it, so ctdb's copy of musicbrainz started falling behind. I've started fixing it a few weeks ago, together with moving wiki to cue.tools domain, upgrading the server and other maintenance tasks, but got distracted ;) I'll try to find the time in coming weeks.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: seaeye on 2016-09-03 21:32:55
hi there.
i've been trying cueripper today on Win10 and... no audio gets extracted at all, only the cue sheet is created :-) and it all ends with a message that the extracted HTOA track cannot be found. before I go and start ranting... is there any debug mode / extra information I can collect and analyze? btw, same in 2.1.6.
thanks!
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NickJP on 2016-09-26 23:25:07
I'm running Cuetools 2.1.5 under Windows 10 x64. The problem I have is that when encoding a CD ripped as separate ALAC tracks in iTunes to a single FLAC file, Cuetools is telling me that one particular ALAC file is not ALAC. The CD is CD1 of Pink Floyd's The Wall: as soon as I click the "Go" button in Cuetools, I get the error msg ".\1-01 In The Flesh_.m4a: Expecting ALAC data format." The file is definitely ALAC - when I look at info for the track in iTunes, it is shown as Apple Lossless audio file. I also completely deleted the album from iTunes and re-ripped all tracks as lossless, but still have the same problem when trying to encode to FLAC. Other Pink Floyd albums that are identically ripped - DSoTM, The Final Cut, and CD2 of The Wall, encode to FLAC no problem.

I've attached screen dumps of the Cuetools error msg and the file properties dialog from iTunes.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-09-27 05:26:07
Cuetools is telling me that one particular ALAC file is not ALAC.
That exception appears when a specific section of data is not exactly as expected. The developer would be able to explain better than I. Hopeful he replies.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 2016-10-29 19:59:24
I stumbled on something strange today : CD-Extra data track length 954394:45:21
It didn't affect my verification at all, it's just for the report (CD is Lauryn Hill - 2002 - MTV Unplugged No. 2.0 CD2).
 
Code: [Select]
[CUETools log; Date: 29/10/16 20:05:40; Version: 2.1.6]
[CTDB TOCID: 0zHUpQp03P50gBflWKEdd405JVM-] found.
        [ CTDBID ] Status
        [5be3c142] (109/234) Accurately ripped
        [9cc324e9] (001/234) No match
        [6ad29a1e] (014/234) No match
        [15dac5fa] (001/234) No match
        [989076c7] (001/234) No match
        [9ac0536a] (055/234) Accurately ripped
        [47c9e051] (011/234) Has pregap length 00:08:00, Accurately ripped
        [47c9e051] (028/234) CD-Extra data track length 00:08:00, Has pregap length 00:08:00, Accurately ripped
        [47c9e051] (007/234) CD-Extra data track length 954394:45:21, Has pregap length 00:08:00, Accurately ripped
        [d922e3d3] (001/234) No match
        [4192cf53] (001/234) No match
        [453067f7] (001/234) CD-Extra data track length 00:08:00, Has pregap length 00:08:00, No match
        [a1ad2fb4] (001/234) Has pregap length 00:08:00, No match
        [8c844554] (001/234) CD-Extra data track length 00:08:00, Has pregap length 00:08:00, No match
        [e519fbb1] (001/234) CD-Extra data track length 00:08:00, Has pregap length 00:08:00, No match
        [741ef1af] (001/234) Has pregap length 00:08:00, No match
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2016-11-07 21:44:36
Here is something that has been driving me crazy. I am using FLAC 1.3.1 in CUETools 2.1.5. For some truly bizarre reason, the FLAC tag, when viewed under "Properties" in foobar2000, does NOT show the md5 checksum.

These are the settings I have:

Code: [Select]
Path: C:\Program Files (x86)\flac-1.3.1-win\win64\flac.exe

Parameters: -%M - -8 -V

Modes: 0 1 2 3 4 5 6 7 8

Name: FLAC 1.3.1

What would cause this tag behavior? I thought that FLAC tags under "Properties" always displayed the md5 checksum by default. I cannot find any command in any documentation online that addresses this issue. In fact, I am unsure how I arrived at the parameters I listed above. (I might have gleaned it from this very thread, about 90 or 100 pages back.) If anyone can suggest a more optimal parameter setting I would  most appreciative.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-11-08 02:16:46
CUETools 2.1.6 includes libFLAC 1.3.1 (Changelog (http://cue.tools/wiki/CUETools_Changelog))
Verify can be turned on in Advanced Settings. (click the gear icon under Audio Output after you select libFLAC)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2016-11-08 03:13:41
How stable is 2.1.6? 2.1.5 is still listed as the latest stable version, even according to this thread. Is there any downside to using 2.1.6 now?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-11-08 03:21:44
Stable (so far). Only a few minor changes since the version bump. Any future changes may require additional testing.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2016-11-08 22:51:19
Installed 2.1.6 and everything is now properly working as it should. Thanks, korth.

I still am puzzled as to why I was getting that checksum bug when using flac.exe in CUETools 2.1.5, particularly when it displays the checksum in the tag properly when I use it to convert in foobar2000. As I stated previously, the FLAC site does not list any command(s) to enable or disable the md5 display, so I cannot imagine how it can be my parameter settings, but whatever. Life is too short to worry about it when I no longer have to.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-11-10 19:00:38
If you want to try the flac.exe again
Code: [Select]
Parameters: -%M -V - -o %O
Modes: 0 1 2 3 4 5 6 7 8
and set the slider to 8
or
Code: [Select]
Parameters: -8 -V - -o %O
Modes:
and not use the slider at all
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Pepzhez on 2016-11-12 08:00:48
That's the solution! Thanks! The FLAC parameters for CUETools sure are confusing. is there a webpage that clearly explains them??
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-11-12 15:09:08
This might help
http://cue.tools/wiki/CUETools_Advanced_Settings:_Encoders#External_encoder_options

Another parameter that probably should be used for the flac.exe is
-P %P
so if the size required for metadata exceeds the default padding, CUETools can add extra.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: chapelno on 2016-11-19 03:31:44
Hi, I've just started using cue tools to split up all my albums currently ripped to a single flac image with a cue sheet.  Sometimes after a conversion is finished I get an error that says "Exception: The process cannot access the file [filepath] because it is being used by another process."

Any clue why this is? It doesn't seem to affect the file quality of the named file. Thanks!
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: chapelno on 2016-11-19 10:00:13
Hi, I've just started using cue tools to split up all my albums currently ripped to a single flac image with a cue sheet.  Sometimes after a conversion is finished I get an error that says "Exception: The process cannot access the file [filepath] because it is being used by another process."

Any clue why this is? It doesn't seem to affect the file quality of the named file. Thanks!

Just realized I didn't include necessary details.  Using CueTools 2.1.5 on a Win 10 PC.  Let me know if there is a log or other info needed to properly diagnose.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2016-11-19 15:01:07
A similar problem with the CTDB (CueTools DataBase) EAC Plugin
https://hydrogenaud.io/index.php/topic,79882.msg911694.html#msg911694

If you check the translated link in my reply, your anti-virus software might be the other process.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Vagetarian on 2016-11-21 20:56:41
I am trying to split a 32bit/192kHz .wv file and keep getting a "Exception: Audio format is not Red Book PCM." error.

Please add support.


Anyone know of a good alternative to CUETools for HD audio?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Apesbrain on 2016-11-22 15:15:10
Quote from: Vagetarian
...
With that username you might enjoy this:
https://m.reddit.com/r/im14andthisisfunny/
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thebrowncriminal on 2016-11-24 16:33:02
I am trying to split a 32bit/192kHz .flac file and keep getting a "Exception: Audio format is not Red Book PCM." error.

Please add support.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: thebrowncriminal on 2016-11-24 16:34:18
I am trying to split a 32bit/192kHz .wv file and keep getting a "Exception: Audio format is not Red Book PCM." error.

Please add support.


Anyone know of a good alternative to CUETools for HD audio?


Were you able to split HD audio?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-01-13 09:32:55
A minor nuissance that is most certainly known:
Entering a minus sign in the offset box does not work unless some nonzero number are written first. Quite often I find it resetting because I mark 0 and start typing.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2017-01-15 17:00:57
Is there any reason why CUETools continues to verify tracks even if they are not in any database?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2017-01-15 17:23:23
I can imagine several reasons.
It checks if the files decode at all.
It checks if the files end on frame boundaries so you may decide there is something wrong.
It checks against the local log.
It creates a log with crcs you can check against an existing log manualy if its format is not recognized by CUEtools.
etc.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2017-01-30 10:52:53
@Gregory S. Chudov
Any chance that we could see an updated version of CUETools with FLAC 1.3.2 & WavPack v5.1.0 or?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-01-30 17:46:31
You can replace the old versions, I guess?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2017-01-30 17:50:34
You can replace the old versions, I guess?

Doesn't work since Gregory have his own dll files with the encoders
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2017-01-30 22:58:58
In due time :) with flac I don't see it as very urgent because there is a built-in encoder that is arguably better. Also I'm on vacation
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-01-31 11:09:30
Maybe you could then even consider updating your signature ;)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Jertzukka on 2017-02-01 17:03:31
I tried googling and finding out myself, but couldn't figure it out. Any way to fix CUERipper making the filenames and replacing ' s with &apos; ? Filenames look like "You Ain&apos;t Got Nuthin" when it should be "You Ain't Got Nuthin"
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-02-01 17:46:31
https://hydrogenaud.io/index.php/topic,79882.msg934265.html#msg934265

With Gregory 'on vacation (https://hydrogenaud.io/index.php/topic,66233.msg934944.html#msg934944)' not sure how long before it will get fixed.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-02-01 18:13:44
Maybe you could then even consider updating your signature ;)
And the first post in this thread. 8)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2017-02-01 18:15:51
 You wouldn't believe how bad the wi-fi is in Cancun and how hard it is to stay sober at an all inclusive resort O:)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: AndrewJB on 2017-02-04 21:40:19
I believe I may have found a bug in CUETools with the tagging.
When I convert my flac files to vorbis with oggenc2, cuetools doesn't actually embed the album art into the file, so not all media players show the album art, and I have to manually add it with mp3tag to the files. However, it works fine when converting to mp3, aac or flac.

I have tested this with several albums in flac from 3 different rippers (Cueripper, EAC and dBpoweramp), all with the same result, and both Cuetools 2.1.5 and 2.1.6.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-02-05 21:22:50
https://wiki.xiph.org/VorbisComment#Unofficial_COVERART_field_.28deprecated.29

Gregory,
CUETools is using COVERART and mp3tag is using METADATA_BLOCK_PICTURE
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: peterpiper on 2017-02-11 00:13:04
............ Any way to fix CUERipper making the filenames and replacing ' s with &apos; ? Filenames look like "You Ain&apos;t Got Nuthin" when it should be "You Ain't Got Nuthin"
Same problem in CUETools:
Run with Audio Output <None>
Then the .cue sheet (and the .m3u) created both will contain " &apos; " which doesn't match the actual filename containing " ' " So the track won't be played.

However running  Action <Create CUE Sheet>
Does create cue sheet with correct " ' " in names. 
Unfortunately I can't get a correct m3u .
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: peterpiper on 2017-02-11 02:56:54
Action <Create CUE Sheet>

Unfortunately the created list puts files in alphabetical order, I can't see an option to use embedded track numbers.
I want a cue sheet to have tracks play in right order without needing tracknumber prefix on filenames.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-02-11 04:46:49
Run with Audio Output <None>
Then the .cue sheet (and the .m3u) created both will contain " &apos; " which doesn't match the actual filename containing " ' " So the track won't be played.
Try unchecking 'Edit Tags'.
http://cue.tools/wiki/CUETools_Settings (http://cue.tools/wiki/CUETools_Settings#.287.29_Action_.7Bsection.7D) (8.1)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rennie on 2017-02-20 13:42:36
Hi!

I'm re-encoding all my ape and flac images to single flac tracks.

I'm doing this using libFLAC with best compression (-8) and the following switches:

-e -m -P 4096

These switches save about 100kb on every single flac track, but unfortunately I have not been able to add these commands to CUEtools.

Thus, I'm splitting my images with cuetools first using the lowest compression rate and then I'm re-encoding the single tracks again with FLAC Frontend and libFLAC 1.3.1 using the switches mentioned above.

Can somebody tell me if there's a way to add these switches to CUEtools?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-02-20 15:08:33
You'll need to register a new external encoder.
Goto Encoders (http://cue.tools/wiki/CUETools_Advanced_Settings:_Encoders):
Click the green +.

Extension: flac
Path: flac.exe (if you copy the exe from the FLAC Frontend tools folder to the CUETools folder) or use the full path (example: C:\FLAC Frontend\tools\flac.exe)
Parameters: -e -m -%M - -o %O -P 4096
Modes: 0 1 2 3 4 5 6 7 8
Name: FLAC 1.31 (or whatever)

Click OK
Restart CUETools (this may not be necessary but I received an encoder error on my first test. Encoder worked fine after.)

Edit: The encoder error I received on my first test was "flac.exe has exited prematurely with code 1". The "Encoder mode" slider needs to be moved to an actual setting before trying to Encode for the first time.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rennie on 2017-02-20 21:30:34
Thanks korth for your help!

...even though it turned out that the files that are created by CUETools with your sequence of parameters can be compressed further by some KB with FLAC frontend using -e -m -P 4096.

It seems that one or more parameters are ignored when your sequence is used.

After changing the sequence of parameters to:

-%M -e -m -P 4096 - -o %O

...the files created by CUEtools can't be compressed further using FLAC frontend.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-02-21 00:56:06
Just to mention it, the FLAC frontend is not safe. It has been eating some of my files, even with the verify option
https://hydrogenaud.io/index.php/topic,99803.msg921798.html#msg921798
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: rennie on 2017-02-21 10:31:13
Just to mention it, the FLAC frontend is not safe. It has been eating some of my files, even with the verify option
https://hydrogenaud.io/index.php/topic,99803.msg921798.html#msg921798

Good to know! Thanks!

...even though this particular problem would not effect me, since I never use the source folder/file(s) as the destination folder/file(s) to be safe.

And I doubt that it's a problem caused by FLAC Frontend. It's more likely that it's a bug of libFLAC itself, because the frontend doesn't encode anything. It's only a GUI for libFLAC.

Thus, I'm pretty sure that you could cause the same effect with CUEtools using libFLAC with the -f (force overwrite) parameter.

Nevertheless I'have to admit that FLAC Frontend isn't very stable on Windows PCs. It crashes always during the seconds operation.

After closing the cmd-window of the first operation you won't be able to complete a second operation successfully.

Maybe you should file a bug report here:

https://sourceforge.net/p/flac/bugs/
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-02-21 10:55:37
I am fairly sure that the the frontend's so-called verify option does nothing to verify whether new audio equals old audio. Because I could use FLAC itself to tell that the MD5s fail to match.
And that is an issue with the frontend; if FLAC fails (for example due to full drive), then the front-end does nothing to check it.

Anyway, I have no sourceforge account, but I replied where the developer announced the front-end, so I assume that no-one responsible is interested.



Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: 44Time on 2017-03-06 16:56:35
Hi everyone, I'm either growing too old nuts or both- I would apreciate a little help.
Ripping to ALAC (cuetools encoder) V2.1.5

Template: g:\cueRIP\%artist%\[%year% - ]%album%[ - %edition%]\%tracknumber% - %title% - %Artist%.cue

this is what the output file looks like:
for cue file "%tracknumber% - %title% - %Artist%"
for m4a files "01 - The Blues - %Artist%" etc

What am I doing wrong?  Why is artist not "printed"?  Anything I can do to make the cue file display something a little more meaningful?  I could not find much on what "edition" really does, I kept hyperlinking back and forth between foobar wiki and cuetools wiki, however I could not find meaningful information/definition on "edition".

Thanx for any helpful input
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2017-03-06 17:20:43
If i had to guess, capital letter A in Artist can be a problem.
"edition" was there just to demonstrate that you can use any custom tag that you might have in your files.
But if you are using musicbrainz metadata via CTDB, what will likely work for you instead is %label%,%labelno%, %labelandnumber%,%releasedate%, %releasedateandlabel% - i think Wiki is not up to date on those.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: 44Time on 2017-03-06 20:18:28
Thank you very much!! This was great info

what will likely work for you instead is %label%,%labelno%, %labelandnumber%,%releasedate%, %releasedateandlabel% - i think Wiki is not up to date on those.

As for the rest:  Could not switch the capital letter for a small one.. kept revertig back to capital.  I deleted the settings file and redit the template... working now... go figure ;-)

EDIT...oops did my little rain dance prematurely... new problem now:  "Excepetion: buffer overflow 8 vs 4096"
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hydrogenate on 2017-03-07 09:40:48
Changing the cue-file name:

By default, CueTools inserts the word "cuetools" into every cue-file name it creates. How do I change the behaviour so that CueTools omits the word "cuetools"?

Thank you.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-03-11 20:13:13
Is there a way to force CUETools to decode through errors?  If CUETools gets the AccurateRip ID right, it would in the very least be able to verify the other tracks.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wally Walters on 2017-03-13 00:35:39
I'm using the CUETools 1.95 command line to batch convert a bunch of my CD rips to FLAC.  Even though I have every AccurateRip option unselected in the GUI version (and thus the template, right?), the program still insists on checking the database and reporting back at the end of conversion.  This has the effect of pausing the batch file after every conversion until I dismiss the resulting dialog.  But the whole point of doing this in batch is to run interrupted.  How can I make it NOT verify my tracks?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-03-13 15:19:36
This has the effect of pausing the batch file after every conversion until I dismiss the resulting dialog.
The command line CUETools.exe wasn't written to continue (end) without user interaction.
edit: It was intended for use in Windows (File) Explorer context menu (not a batch script).
If you are converting tracks, have you tried CUETools.Converter.exe?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wally Walters on 2017-03-14 06:27:28
No, I hadn't tried that.  It was my understanding it didn't work on CUE sheets.  Are there any other CLI programs that can use a CUE sheet to bundle audio tracks into an image file (uninterrupted)?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radorn on 2017-04-09 02:10:05
Recently I was trying to verify/convert a rip and got this:
"Exception: Index was out of range. Must be non-negative and less than the size of the collection."
I looked at the CUE file's "INDEX" entries, trying to figure out if there was something funny with them, but other than the typical INDEX 01 00:00:00, there were just a handful of INDEX 00 with timecodes that were well in range. It was a CUE+Tracks rip.
After going back and forth trying a few things and scratching my head, I was lucky enough to notice that the filenames in some FILE entries were missing the closing quotes ["]. The filenames were rather long, and I was misled by the error message into thinking that the problem was with the INDEX entries, so I didn't pay attention to them.
After fixing that, the CUE file finally worked.

This was with version 2.1.6, haven't tried earlier ones.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-04-17 07:21:35
Here is a case where CUETools and fb2k on one hand, compute the AccurateRip (V1) checksum different from what dBpoweramp and PerfectTunes do:

AccurateripID: 001e83c5-01459edf-c10e8c0e, track 11.  (They agree on all the thirteen other tracks.)

Spoon's applications (PerfectTunes just now, dBpoweramp v14 from the log back in 2010) calculate it to C139D799, verified with confidence = 2 (one of them is my own rip).
CUETools and foobar2000 calculate it to c1a31099.

I probably need to upload the track?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-04-21 20:19:25
I have mentioned this before I think, but never uploaded it. A sample of probably some of the worst few seconds that CUETools ever repaired: https://hydrogenaud.io/index.php/topic,113978.new.html
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2017-04-22 19:36:59
A little 'request'...... what about making it possible to use a FLAC Binary with this great tool of yours Gregory.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-04-22 22:40:35
Use exe as an external encoder
https://hydrogenaud.io/index.php/topic,66233.msg935914.html#msg935914
https://hydrogenaud.io/index.php/topic,66233.msg930761.html#msg930761
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NetRanger on 2017-04-22 23:20:24
Thnx for the reminder korth. Totally forgot about that.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: madmalkav on 2017-05-10 16:11:12
Anything I can do for Cueripper to write unicode filenames on the CUE? The filenames are OK after I found the tip about editing settings.txt in %appdata% and changed the ANSI safe filename param to 0 but the CUE still uses ANSI.  If I load the flac files on Cuetools and generate CUE then it have proper unicode filenames inside.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Lexeremo on 2017-06-09 22:34:35
I'm getting the error "Exception: First index must start at file beginning"

Please help me =(

Quote
REM GENRE Game
REM DATE 2009
REM DISCID A910410D
REM COMMENT "ExactAudioCopy v0.99pb5"
PERFORMER "EastNewSound"
TITLE "Sacred Factor"
FILE "Sacred Factor.tta" WAVE
  TRACK 01 AUDIO
    TITLE "song for bird"
    PERFORMER "リツカ"
    INDEX 01 00:02:00
  TRACK 02 AUDIO
    TITLE "Your Color"
    PERFORMER "Cryu"
    INDEX 01 04:55:08
  TRACK 03 AUDIO
    TITLE "Lucid Dream"
    PERFORMER "茶太"
    INDEX 01 10:45:40
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-06-10 04:35:39
The file should begin at 00:00:00
Track 01 begins at 00:02:00

Add INDEX 00 00:00:00 to show where the file begins.
Quote
FILE "Sacred Factor.tta" WAVE
  TRACK 01 AUDIO
    TITLE "song for bird"
    PERFORMER "リツカ"
    INDEX 00 00:00:00
    INDEX 01 00:02:00
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hydrogenate on 2017-06-30 14:27:35
Sorry, posted in wrong section.  :-[ 
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Coreda on 2017-07-19 10:20:44
So this has been an issue for a little while (perhaps six months?), metadata sourced from Discogs now adds a space and comma character after the Artist tag, despite it not displaying as such in the CUERipper UI.

So it will display as say, The Beatles in the CUERipper UI, but when ripped it will output to The Beatles , - which will include directories and filenames if that's part of the user's output template.

Using v2.1.5
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Cellfish on 2017-08-04 21:14:45
Thank you for making CUETools.  I love it, and use it all the time :)

Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: grim_lokason on 2017-08-12 18:32:23
Hi !
It seems that the sync between CTDB and musicbrainz is down again.
 ( probably because of : https://blog.musicbrainz.org/2017/05/16/schema-change-release-2017-05-15-including-upgrade-instructions/ )

Is it possible to have a look ?

Best Regard, and thanks for your work :D
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-09-05 19:19:47
A bug-ish behaviour that may be known:

When there is already a CDTOC, CUETools may sometimes write a second one. And I will have e.g.
11+96+4D77+B2EB+10223+186D4+1F433+26051+2BBDA+30844+3461B+3737B+38B30+3C070+3DEBE+42930+48EA4+4F095+55115; 11+96+4D77+B2EB+10223+186D4+1F433+26051+2BBDA+30844+3461B+3737B+38B30+3C070+3DEBE+42930+48EA4+4F095+55115
note: both are equal
- and next time I try to verify, CUETools refuses to recognize that track as part of the CD with the others.

Suggestion: if the CDTOC-to-be-written is the same as one already present, do not write.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BigBertrand on 2017-10-15 05:25:40
As reported on this user talk page,[1] the wiki page CUETools Download (http://cue.tools/wiki/CUETools_Download) may need to be updated.

(by the way, this thread's first post (https://hydrogenaud.io/index.php/topic,66233.0.html) needs to be updated too :)

link removed
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-10-26 20:19:30
I did a round of AccurateRip-retroverification ... I know that ripping without cross-pressing checking is soooo last decade, but about ninety percent of my rips were done before dBpoweramp implemented that feature.
So out of about 7250 CDs, approx.:
* 3800 were Accurate upon ripping;
* 2500 more verify (confidence at least 2, since "1" would be mine - except some purged submissions); a few by PerfectTunes, but most of them by CUETools.
... out of the 2500, 51 were repaired by CUETools first.
* 700 are still the only submission (many self-released and from basement labels);
* 150 seem to have a competing entry, not sure if mine or the other is right
* 70 are bad rips
* 30 are HDCDs which I decoded upon ripping. Ignorance, argh.

So if (*guess!*) half the "competing entry" ones are indeed bad, then CUETools managed to repair 1/4 of my bad rips.
Despite an "adverse" selection: I re-ripped a few CDs which upon ripping had some Accurate and one or two Inaccurate tracks - and if they were not that rare, they should have had a better chance of being repairable.

Not counting classical music (different folder, must be counted manually, too lazy) .


And, a gentle bump, while I'm at it:
Here is a case where CUETools and fb2k on one hand, compute the AccurateRip (V1) checksum different from what dBpoweramp and PerfectTunes do:


Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2017-10-26 20:41:17
Thanks, very interesting statistics.

In my dream universe record labels (including the basement ones) would submit reliable data to the database for each CD they plan to print, so even if there are consistent errors in all the copies we could still all repair them ;)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2017-10-26 21:36:26
In a not-so-optimal universe, I still keep my CDs ... but hell I do not want to re-rip. Ever. That was some job ...

By the way, you need to upgrade your signature :-o
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Putsli on 2017-10-28 13:47:36
Greetings!
When I transcode flac into aac using CUETools.Converter, the entries in the main tags of the new file are duplicated, like: "ALBUMARTIST: Al Chem; Al Chem" How can I fix this?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wally Walters on 2017-10-31 20:57:20
When using "CUETools.exe /convert" in a batch file, how can I make the GUI automatically exit after it's finished processing?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dpr on 2017-11-10 09:02:19
Hi, I'm unable to encode compilations with Cuetools 2.1.5.

I have a CUE file with the COMPILATION flag set, and can encode mp3 files for all of the tracks. Other meta data from the CUE file is created as tags in the mp3 files, but not the 'part of a compilation'.

I am new to using Cuetools, but not to cuefiles;  I have a number of images and cue files that i created with eac and have successfully encoded using LAME to create these files with the metadata including the compilation flag.

The input cue file has the following:

REM GENRE Christmas-Rock
REM DATE 1963
REM DISCID B4083E0D
REM COMMENT "ExactAudioCopy v0.99pb3"
REM COMPILATION 1
PERFORMER "Various Artists"
TITLE "A Christmas Gift for You from Phil Spector"
etc

All of the mp3s are created with the year, genre and the Various Artists performer from the cue file, but the "Part of the Compilation" flag is not set.  I have also tried changing the REM COMPILATION 1 line to REM COMPILATION TRUE.

I must be missing something obvious. Please can anyone clue me in? Also how to post 'code snippets'
Thanks
dpr






Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ManekiNeko on 2017-11-28 11:58:11
For converting a huge amount of image+cue files to lossy files, is there a way to NOT have the cue file copied over to the destination directory. I tested with 2.15 and haven't been able to stop the cue file being copied. Is there a newer build with the option? Thanks
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-11-28 13:28:19
https://hydrogenaud.io/index.php/topic,66233.msg819468.html#msg819468
Option to not write the CUE hasn't been added as of the current version.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ManekiNeko on 2017-11-28 17:31:38
https://hydrogenaud.io/index.php/topic,66233.msg819468.html#msg819468
Option to not write the CUE hasn't been added as of the current version.

I've just tried with 2.1.6 (The current version?) and it's still writing the cue file when converting to lossy m4a files.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hydrogenate on 2017-12-05 14:31:47
CUETools 2.1.6. & Windows 7 x64

Hi  :)

During the process of splitting a single FLAC into multiples, CUETools abruptly stops the process, and displays this error message:

"flac.exe has exited prematurely with code 1: The pipe has been ended."

Could someone please explain what causes this, and perhaps offer the appropriate solution?

Thank you.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2017-12-05 18:32:36
flac will exit with code 1 if there were any errors, including when the MD5 checksum doesn't match the audio.
Can you run Action:Verify on the input without error?
You can also test your input file for errors with the flac frontend (http://flacfrontend.sourceforge.net/) or with the flac command-line flac.exe -t yourinputfile.flac
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2017-12-05 18:37:29
If it happens right away, it might be due to wrong command line parameters.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gehirnmaehung on 2017-12-06 14:21:20
I use CUERipper to convert CDs to flac and it works great, really nice little tool!

I have a questions though where i am unsure how i can do that with CUERipper.
- Is it possible to keep the .wav as well?
- is it possible to write ReplayGain Info into the cue?

Thanks!
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hydrogenate on 2017-12-06 15:29:03
Thank you both for responding.

flac will exit with code 1 if there were any errors, including when the MD5 checksum doesn't match the audio.
Can you run Action:Verify on the input without error?
You can also test your input file for errors with the flac frontend (http://flacfrontend.sourceforge.net/) or with the flac command-line flac.exe -t yourinputfile.flac

Yes, Action: Verify verifies the input without error. Both CTDB & AccurateRip display "accurately ripped" No errors there.

FLAC Frontend gives this error on input of the same file:

*** Got error code 0:FLAC__STREAM_DECODER_ERROR STATUS_LOST_SYNC
filename.cue: ERROR while decoding metadata state = FLAC__STREAM_DECODER_END_OF_STREAM

If it happens right away, it might be due to wrong command line parameters.

It does not happen right away.

Is it possible, using CUETools, to split the album-file right though the error, i.e. ignoring the error? That way, one can at least harvest all the tracks, to find the faulty one to possibly repair, and gain all all the good ones. 

May I also ask if CUETools is capable of splitting single track 24-bit albums into multiple tracks from the cue file? If not, would you kindly please recommend an application that can do that? I do not want to downsample the files.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: hydrogenate on 2017-12-07 10:42:04
Quote
Is it possible, using CUETools, to split the album file right though the error, i.e. ignoring the error? That way, one can at least harvest all the tracks, to find the faulty one to possibly repair, and gain all all the good ones.

May I also ask if CUETools is capable of splitting single track 24-bit albums into multiple tracks from the cue file? If not, would you kindly please recommend an application that can do that? I do not want to downsample the files.

I have now found and deployed two different applications, both of which addressed the aforementioned points quite easily. The first was addressed using dbPoweramp, and the second with Foobar Convert.

Thank you all who responded.

Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: plugs13amp on 2017-12-07 14:05:39
is there a way to NOT have the cue file copied over to the destination directory.

no, but its easy to remove them. However, NOTE: the second cue is not a copy, one is an image file cue and the other is a track files cue

Open Windows Explorer, and shift-rightclick on the base folder for your converted rips and click on "Open Command window here". Check the prompt to make sure window opened at the right place, then type "del /s *.cue" without the quotes, and press return. This will step down all your folders and subfolders below the one you started in and delete anything with a .cue extension. Take care you get it right, it won't ask if you're sure.

If you've been upgraded to Windows 10 Creators Edition, the "Open Command window here" option has been removed so you'll have to use PowerShell. Click "Open PowerShell window here". This uses a different syntax, type "get-childitem . -recurse -include *.cue | remove-item" without the quotes, check what you've typed is correct, and press return.

Your .cues will be gone.

Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wahnsinn on 2017-12-08 14:44:46
Hi. LOVE CueTools for verifying rips.

Couple small quality of life improvements I would suggest:
1) the results are displayed as text, formatting and color scheme in accordance with the Windows theme. While perfectly readable, it's far from convenient. It would be really nice to have some form of color coding here: e.g. shades of green show that it's "accurately ripped" with ok-good-great confidence, yellow for low confidence, red for not accurately ripped).
I usually open the .accurip file in a text editor, which is set up to parse and color code in that fashion, but it's not a perfect solution by far, and having CUETools itself color code the results would be very much appreciated.

2) Multiselect Browser: two things here:
a) the directory tree shows way too many items by default
Example: Let's say I've got two CDs in "F:\music\something\cd1" and "F:\music\something\cd2". I paste their parent directory path ("F:\music\something") in CUETools input field. I then click on the little green icon, opening the multiselect browser (this is how I typically go about it). If I want to change any of the (automatically set) check marks, I have to do a whole lot of scrolling before I get to the input folder. This is because the multiselect browser shows the following, in order from bottom to top:
- Local DB (8 items),
- all directories on user's Desktop (in my case about 20 items),
- Windows "users\username" directory (1 item),
- Windows "My Music" and "Public Music" directories (2 items),
- Root of drives with drive letters higher than the one the actual input is on (in my case: Drive "I:" and "G:" are higher than "F:" so 2 items),
- any directory in the root of the same drive that has the input files (so all directories in the root of "F:" - potentially many items),
- any directory that has the same parent directory as the input (i.e. all directories in "F:\music\" -- many items)

I suggest auto-focusing the view (i.e. scrolling up automatically) to the item(s) that are automatically selected (check marks).


b) auto-selection of items in the above scenario should be configurable by file type. I don't see the need to auto-select the audio files themselves in addition to the cue sheet. The cue is all you want, usually.


Thanks for considering + thanks for the fantastic program!
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dpr on 2017-12-29 17:23:56
Cuetools seems to ignore some Metadata that is in MusicBrainz.

After I was told that Cuetools ignores Metadata after the REM in a CUE file, I decided to see if how GENRE, Part of a Compilation and Date are handled by Cuetools.  I removed all of this information from a CD and then used Cuetools to encode from the .wav and .cue file to MP3 with all of the lookups in CTDB turned on. 

I found that Genre, Year, Part of a Compilation, Composer and disc3  tags in the MP3s were not filled in even though the information is in the MusicBrainz entry for the CD concerned. https://musicbrainz.org/release/a5939b2e-841a-4dbf-8e1c-1f9a519c5f53

Composer also has a place in the standard CUE file where it could be filled in.

Is there a way to make these get copied in?

Thanks
dpr




Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dpr on 2017-12-31 22:25:22
 c:\lame\lame.exe has exited prematurely with code 1: The pipe has been ended.

I'm trying to use the external encoder - lame, so I can control the tags, but I get the error message above when I try to encode to tracks using VBR(lame.exe). the settings are

Path: c:\lame\lame.exe
Parameters: --vbr-new -b %M - %O


error message:
.\Various Artists - KBCO Studio C, Volume 19.cue: c:\lame\lame.exe returned error code 1.

all works ok with VBR(libmp3lame) and with the external lame.exe for CBR:
Parameters: -m s -q 0 -b %M --noreplaygain - %O

thanks for any hints





Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-01 01:49:29
c:\lame\lame.exe has exited prematurely with code 1: The pipe has been ended.
Parameters are probably wrong.

Quote
I'm trying to use the external encoder - lame, so I can control the tags
You can't control the tags from the encoder. CUETools handles all tags using internal taggers (e.g. TagLibSharp).

Quote
I try to encode to tracks using VBR(lame.exe). the settings are

Path: c:\lame\lame.exe
Parameters: --vbr-new -b %M - %O
Looks like a mix of VBR and CBR. You didn't provide the 'Modes' line to show what is being replaced for %M.
http://cue.tools/wiki/CUETools_Advanced_Settings:_Encoders
https://svn.code.sf.net/p/lame/svn/trunk/lame/USAGE
http://wiki.hydrogenaud.io/index.php?title=Lame#VBR_.28variable_bitrate.29_settings
http://wiki.hydrogenaud.io/index.php?title=Lame#CBR_.28constant_bitrate.29_settings

Cuetools seems to ignore some Metadata that is in MusicBrainz.
CUETools gets metadata from the CTDB. The CTDB (CUETools Database) replicates and stores relevant data from MusicBrainz (and other databases).
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dpr on 2018-01-01 10:13:08
c:\lame\lame.exe has exited prematurely with code 1: The pipe has been ended.
Parameters are probably wrong.

yes, thanks. I corrected it:
--vbr-new -%M - %O

Quote
I'm trying to use the external encoder - lame, so I can control the tags
You can't control the tags from the encoder. CUETools handles all tags using internal taggers (e.g. TagLibSharp).

This is frustrating. It would be much more helpful to have access to the tags to pass to lame in the call to an external encoder.  Why not have them listed out in the Parameters to the encoder?

Cuetools seems to ignore some Metadata that is in MusicBrainz.
CUETools gets metadata from the CTDB. The CTDB (CUETools Database) replicates and stores relevant data from MusicBrainz (and other databases).
I am not sure this is correct or complete.  My post included:
I found that Genre, Year, Part of a Compilation, Composer and disc#  tags in the MP3s were not filled in even though the information is in the MusicBrainz entry for the CD concerned. https://musicbrainz.org/release/a5939b2e-841a-4dbf-8e1c-1f9a519c5f53
 

If you look at the image (see attached) or  link you will see  the tags I listed: Genre, Year, Part of a Compilation, Composer and disc#  tag are in MusicBrainz. These do not get output to the mp3s built with Cuetools. I dont know if there are dropped by CTDB or Cuetools or not available in the MusicBrainz, but they are in MusicBrainz. 
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-01 17:16:12
The developer may respond at some point after the holidays.
Compilation & Composer are not supported by CUETools. Genre may be included as part of Tags (https://musicbrainz.org/doc/Folksonomy_Tagging) on MusicBrainz but almost anything else can be stored there as well. The CTDB does not store genre from MusicBrainz.
Year and discnumber are stored.
You didn't provide the CTDB TOCID for your rip so I couldn't look it up.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dpr on 2018-01-01 20:59:12
Where do i find that?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-01 22:05:52
Where do i find that?
With default settings, a log file named *.accurip should be in the folder with your mp3 files.
edit: this file can be read in a text editor such as notepad.
If you converted a single rip, the log also appears in the window at the bottom of the GUI at the end of the process.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sebus on 2018-01-02 17:53:47
Is there a way to converts only specific tracks from cue/flac to a different format (ie mp3)
I have few images as cue/flac but only need a single track from each

Of course I can convert the lot & delete what is not needed, but...

sebus
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dpr on 2018-01-02 21:40:54
Where do i find that?
With default settings, a log file named *.accurip should be in the folder with your mp3 files.
edit: this file can be read in a text editor such as notepad.
If you converted a single rip, the log also appears in the window at the bottom of the GUI at the end of the process.

[CTDB TOCID: mMLhhVycNz0hAIEqDFiVchLC7NA-] found.

Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-02 22:53:22
Is there a way to converts only specific tracks from cue/flac to a different format (ie mp3)
Not with CUETools

[CTDB TOCID: mMLhhVycNz0hAIEqDFiVchLC7NA-] found.
http://db.cuetools.net/?tocid=mMLhhVycNz0hAIEqDFiVchLC7NA-
http://db.cuetools.net/cd/798197
xml for mMLhhVycNz0hAIEqDFiVchLC7NA- (http://db.cuetools.net/lookup2.php?version=3&ctdb=1&metadata=extensive&fuzzy=1&toc=0:18099:35607:53850:73247:108432:126844:145401:166313:182162:201171:216657:236340:246821:268911:292515:308170:325380)

disc: 1/2
year: 2008
release date: 2008-12-06

edit: the metadata available to CUETools is in the xml
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: dpr on 2018-01-06 13:14:25
[CTDB TOCID: mMLhhVycNz0hAIEqDFiVchLC7NA-] found.
http://db.cuetools.net/?tocid=mMLhhVycNz0hAIEqDFiVchLC7NA-
http://db.cuetools.net/cd/798197
xml for mMLhhVycNz0hAIEqDFiVchLC7NA- (http://db.cuetools.net/lookup2.php?version=3&ctdb=1&metadata=extensive&fuzzy=1&toc=0:18099:35607:53850:73247:108432:126844:145401:166313:182162:201171:216657:236340:246821:268911:292515:308170:325380)

disc: 1/2
year: 2008
release date: 2008-12-06

edit: the metadata available to CUETools is in the xml



Korth, Thanks for the XML.
Looking at the xml, the musicbrainz entry;
- does not include Genre, but  freedb one does.
- the year is in the xml
- the release type is missing, in the musicbrainz entry this is where 'part of a compilation; (Compilation) is stored.
- per track composers are not listed in the xml for the musicbrainz entry., (there are some for this release in musicbrainz
- the disc number and total number of discs are in the xml.

I removed Cuetools and did a reinstall and then an encoding for this CD. The results were:

1. Year is correct
2. Genre is missing - not in entry
3. Part of compilation missing
4. Composer per track missing

as you say above, they are 'Compilation' is supported by cuetools...

Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wahnsinn on 2018-01-09 15:02:59
- Where is the Local DB stored?
- How do you purge the Local DB?
 The changelog mentions this was added as early as 2011, but I can't seem to find that option.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-09 17:36:22
The database file is named LocalDB.xml.z
A new file will be created (as needed) if you delete it.
You'll find the file in \CUE Tools
If you're running CUETools as portable \CUE Tools is a sub-folder
otherwise the location is %appdata%\CUE Tools
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-09 19:17:47
I can't seem to find that option.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: wahnsinn on 2018-01-10 00:13:45
Thank you for the detailed response!

Deselecting that option did not purge the db in my case - unless we mean different things by purging (I mean emptying it).

Anyway, I will simply delete the file! Thanks for your help :)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-10 04:36:08
Sorry, wrong pic. The other was for adding to the db.
To purge records (from Folder Browser or Multiselect Browser) right-click mouse on the record you want to purge (remove).
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2018-01-13 12:35:39
A word of warning to those using CUETools 2.1.6 on linux (WINE): Do not use the libFLAC decoder! For some reason, it doesn't produce valid output. The audio checksum differs on every decoding attempt (verify/encode), and of course no accurateRip/CTDB match is possible.

Changing to cuetools decoder solves the issue. I wasted a day trying to figure out why all my windows PCs report 70/70 match while all my linux PCs report 0/70, using the exact same portable CUETools installation.

Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: arkhh on 2018-01-13 15:54:00
A word of warning to those using CUETools 2.1.6 on linux (WINE): Do not use the libFLAC decoder! For some reason, it doesn't produce valid output. The audio checksum differs on every decoding attempt (verify/encode), and of course no accurateRip/CTDB match is possible.

Changing to cuetools decoder solves the issue. I wasted a day trying to figure out why all my windows PCs report 70/70 match while all my linux PCs report 0/70, using the exact same portable CUETools installation.



And how do you get it to work on wine? Last time I tried it didn't work. Which version of wine and .NET did you use?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ChronoSphere on 2018-01-13 16:22:46
edit: I just tested it out:

- install wine (any version really, it's been working for me for several years, I'm currently using 3.0rc6)
- install wine-mono (or whatever it is called on your distribution)
- create a new win32 prefix (WINEARCH=win32)
- install dotnet20sp2 using winetricks. It shows a couple of errors (i.e. "mono not installed", even though it is), but the process finishes fine
- install vcrun2008
- copy the CUETools folder to your prefix/drive_c/Program Files/
- launch CUETools.exe with WINEPREFIX set to your prefix

It takes a while to launch, but it does launch fine. The only problem I had was that configuring it as I wanted crashed on some steps.
What I did was configure it as I want on a windows machine, then copy the settings.txt to my linux one.

I've also created a desktop file for each of them:
CUERipper:
Code: [Select]
[Desktop Entry]
Categories=AudioVideo;Audio
Comment[en_US]=Secure CD audio ripper
Comment=Secure CD audio ripper
Exec=WINEPREFIX=/path/to/prefix/ wine "/path/to/prefix/drive_c/Program Files/CUETools/CUERipper.exe"
GenericName[en_US]=
GenericName=
Icon=media-optical-audio
MimeType=
Name[en_US]=CUERipper
Name=CUERipper
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
Version=2.1.6
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=

CUETools:
Code: [Select]
[Desktop Entry]
Categories=AudioVideo;Audio
Comment[en_US]=CD audio converter/verifier
Comment=CD audio converter/verifier
Exec=WINEPREFIX=/path/to/prefix wine "/path/to/prefix/drive_c/Program Files/CUETools/CUETools.exe"
GenericName[en_US]=
GenericName=
Icon=media-optical-audio
MimeType=
Name[en_US]=CUETools
Name=CUETools
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
Version=2.1.6
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radorn on 2018-01-15 01:59:38
I would like to request some changes:

1: Change the behavior of the offset textbox so that it doesn't fix invalid input as you type, but only after it loses focus. The reason is every time I try to insert negative offsets, either by first deleting the existing content, or selecting the content and start typing over it, starting with the [-] minus/dash character, the box replaces my input with a [0] and sets the cursor to the left.

2: Please, add AccurateRip V2 confidence numbers to the non-zero offsets too.

3: This one is not really that important, but while I'm at it, I might as well ask for it: The offets seem to be ordered alphabetically in the report, instead of logically by numeric value, as would be intuitive in this case. Either making the sorting "smart" or zero-padding the offset values to help the "non-smart" sorting would work for me.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radorn on 2018-01-15 06:04:26
The forum mangled my post. At the end of point 1, it should be:
"the box replaced my input with a [ 0 ] and sets the cursor to the left"

It seems "[ 0 ]" without the spaces gets processed as a numbered list item...
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: radorn on 2018-01-16 05:27:50
Sorry for triple-posting: Any plans to add UTF-8 log writing?

Thanks I love this program. I use it a lot to process many rips.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: arkhh on 2018-01-16 21:44:50
edit: I just tested it out:
Spoiler (click to show/hide)

It's alive!  :)

Thanks, after tinkering a bit with wine and playonlinux I got CUETools working with no problems. Fortunately I had my old windows config from the days of winXP floating around with all my presets and everything...

Before this I was running it with mono on linux, but that way only works with WAV files, now I can save an extra step of transcoding and some tagging... and verifying in one step is much easier.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-01-17 09:50:52
edit: I just tested it out:

- install wine (any version really, it's been working for me for several years, I'm currently using 3.0rc6)
- install wine-mono (or whatever it is called on your distribution)
- create a new win32 prefix (WINEARCH=win32)
- install dotnet20sp2 using winetricks. It shows a couple of errors (i.e. "mono not installed", even though it is), but the process finishes fine
- install vcrun2008
- copy the CUETools folder to your prefix/drive_c/Program Files/
- launch CUETools.exe with WINEPREFIX set to your prefix

It takes a while to launch, but it does launch fine. The only problem I had was that configuring it as I wanted crashed on some steps.
What I did was configure it as I want on a windows machine, then copy the settings.txt to my linux one.
is there any benefit to install wine-mono in first place when dotnet20sp2 gets installed right afterwards? afaik, mono is a replacement for dotnet and gets uninstalled by winetricks when you attempt to install dotnet anyways.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-01-17 16:52:40
A word of warning to those using CUETools 2.1.6 on linux (WINE): Do not use the libFLAC decoder! For some reason, it doesn't produce valid output. The audio checksum differs on every decoding attempt (verify/encode), and of course no accurateRip/CTDB match is possible.
i just tested and split an accurate flac image of mine with libflac and with cuetools encoder under wine 3.0 rc5.

the result is still accurate, but the bitrate of the libflac encoded files are higher by 2 bits and the encoder is also much faster!

which version of wine do you use? have you tried a new prefix?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-01-17 18:09:48
A word of warning to those using CUETools 2.1.6 on linux (WINE): Do not use the libFLAC decoder! For some reason, it doesn't produce valid output. The audio checksum differs on every decoding attempt (verify/encode), and of course no accurateRip/CTDB match is possible.
sanskrit44, did you test using the libFLAC decoder? (I haven't tested myself, just looking for more information)

[attachimg=1]
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-01-17 19:07:42
no, i have tested the encoders. no differences between libflac and cuetools on my side. btw it was a wav image that i had split up. my mistake.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-01-17 19:35:40
ok, i have tested again (flac image this time) and set libflac encoder + decoder and the result is still accurate.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2018-01-22 04:36:51
The only problem I had was that configuring it as I wanted crashed on some steps.
What I did was configure it as I want on a windows machine, then copy the settings.txt to my linux one.

Do you know where I find this settings.txt file? I have CUETools running in an XP VM. I would love to not have to use a VM to run CUETools, it's the only WIndows program I use. Thanks!
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Corwin on 2018-01-22 05:44:19
Wow, I've been running CUETools 2.1.5 in kvm (Linux VM) with XP for years. Running CUETools 2.1.6 under wine 3.0 on the same system is 7.5x faster (6 seconds vs 45 seconds) for a verify on the same album. Fortunately I did not encounter any crashes using wine, all the config screens worked fine. The font size is microscopically small on my 4K monitor though.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: fireattack on 2018-02-12 08:23:49
I was wondering if there is any possibility to add a "blank/unknown" option for metadata, or simply a button to erase all the info.

I often encounter some singles that don't have the right information in the DB, but CUEripper will auto-select the first result. Then, I have to remove all the fields one by one (I do just override some, but there are some of the fields I never manually fill in, like barcode, so I still need to delete them).

Thanks!
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: BigBertrand on 2018-03-10 06:46:45
I often start CUETools, and even if my computer is not a beast, I'm noticing the program is a bit slow to start.

I have had unchecked "Check for updates" to avoid network request at startup, but that was not the culprit.

So, I just investigated a bit using Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon):
* One of the main culprit seems to be csc.exe. It seems that at each startup you are compiling stuff on the fly, which is temporarily put in the Windows temp folder. Maybe the compilation results could be cached/stored and reused? (I guess that's what Paint.net (https://www.getpaint.net/) does)
* The form drawing might also takes some time. Maybe raising the .NET Framework version could help? 2.0 is quite outdated... (on a related note, I found an article (http://kynosarges.org/WpfPerformance.html) that might be of interest)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-03-10 13:51:24
Yeah, the csc.exe problem was also recently discovered with CUETools EAC plugin. Turns out that how Xml serialisation works in .net - it compiles the data types to an Xml serializer class on the fly and doesn't even cache the result, but it's possible to pre-compile it and ship with the product. It's already fixed in the plugin, will be fixed in the next CUETools release also.

As for WPF/4.0, i've been playing with it, and i plan to do it sometime. CUETools has so many controls though, that creating a WPF UI for it is a LOT of work.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2018-03-13 01:04:44
Maybe  some are interested in a new CUETools_2.1.7.zip - Latest experimental/dev build (for testing; may be unstable) (http://cue.tools/wiki/CUETools_Download)
No idea what it does.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: deus-ex on 2018-03-13 02:17:05
Hey, thanks for the hint, I am interested.
As to you wondering what the update does, the answer can be found in the post right above yours.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-03-13 02:50:46
I'm only starting with 2.1.7 work. Version bump is the first step so 2.1.6 can be now officially declared the stable version. I'll update the change log at some point, but for now there's not much news, mostly housekeeping. Updated libFLAC version, added support for tagging opus files, switched to using .NET Framework 4.0... I guess the only exciting thing is BLUTools, which is in very early stages, and is meant to extract PCM audio tracks from audio Blurays. Just point it to an input folder with unencrypted Bluray copy, choose output folder, select a title set etc and click the copy button.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ozz on 2018-03-14 10:24:16
How can I connect a new Monkey's Audio 4.33 as an external encoder?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ozz on 2018-03-14 13:53:24
version 2.1.7 does not copy the images from iso.wv to the folder with the converted CD. In 2.1.6 is OK.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-03-15 11:49:33
How can I connect a new Monkey's Audio 4.33 as an external encoder?
External encoders must support piping (stdin/stdout).

version 2.1.7 does not copy the images from iso.wv to the folder with the converted CD. In 2.1.6 is OK.
Working here. Front cover was extracted from image.wv to folder.jpg
Prerequisites (http://cue.tools/wiki/CUETools_Download#Version_2.1.7_Prerequisites) for 2.1.7
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ozz on 2018-03-15 15:48:36
External encoders must support piping (stdin/stdout).
but it was Monkey's Audio that I failed to get to work
Working here. Front cover was extracted from image.wv to folder.jpg
Prerequisites (http://cue.tools/wiki/CUETools_Download#Version_2.1.7_Prerequisites) for 2.1.7
Version 2.1.6 does so. But in 2.1.7 the picture is not extracted
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-03-15 20:22:39
External encoders must support piping (stdin/stdout).
but it was Monkey's Audio that I failed to get to work
Are you using a patched version that supports stdin/stdout? 
This will work in 2.1.7
mac.exe v3.99 (http://www.etree.org/shnutils/shntool/support/formats/ape/win32/3.99-u4-b5-s7/mac.exe) (a special version that is patched to support stdin/stdout)
put mac.exe in CUETools folder
Extention: ape
Path: mac.exe
Parameters: - %O -c%M
Modes: 1000 2000 3000 4000 5000
Name: mac.exe v3.99

or use the built-in MAC_SDK
If you don't see the built-in MAC_SDK then check the Prerequisites (http://cue.tools/wiki/CUETools_Download#Version_2.1.7_Prerequisites)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ozz on 2018-03-16 05:38:47
External encoders must support piping (stdin/stdout).
but it was Monkey's Audio that I failed to get to work
Are you using a patched version that supports stdin/stdout? 
This will work in 2.1.7
mac.exe v3.99 (http://www.etree.org/shnutils/shntool/support/formats/ape/win32/3.99-u4-b5-s7/mac.exe) (a special version that is patched to support stdin/stdout)
put mac.exe in CUETools folder
Extention: ape
Path: mac.exe
Parameters: - %O -c%M
Modes: 1000 2000 3000 4000 5000
Name: mac.exe v3.99

or use the built-in MAC_SDK
If you don't see the built-in MAC_SDK then check the Prerequisites (http://cue.tools/wiki/CUETools_Download#Version_2.1.7_Prerequisites)

I know about the built-in encoder. I was interested in the encoder of the latest version 4.33, but it does not work. Special encoder. to which you gave a link too refuses to work . Exception returned code -1.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: lvqcl on 2018-03-16 05:57:17
IIRC this special version works with stdin on Linux, but not on Windows.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-03-16 11:46:13
I'll soon update CUETools to Monkey's Audio 4.33. In my tests it's going to be slightly slower though, due to the lack of assembly optimisations present in the old library. I'm too lazy to port them over.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ozz on 2018-03-16 11:49:42
I'll soon update CUETools to Monkey's Audio 4.33. In my tests it's going to be slightly slower though, due to the lack of assembly optimisations present in the old library. I'm too lazy to port them over.
please still correct copy of images from an iso iso.wv
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-03-16 12:10:46
IIRC this special version works with stdin on Linux, but not on Windows.
It was a pointless exercise anyway <edit> beyond showing the OP that a patched exe was needed for stdin/stdout </edit> as that version isn't newer than the current built-in MAC_SDK. I did test the linked exe before posting and it is working here on 2 machines and on both v2.1.6 & v2.1.7 without error.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-03-18 20:21:47
cuetools 2.16 prerequisites lists net framework 2.0sp2 & vcrun2008.

today i created a fresh 64bit wineprefix, installed only dotnet20sp2 (x64) and to my surprise, cuetools (libflac) was working just fine.

in the changelog of cuetools you find:

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.

is vcrun2008 needed at all?

p.s. it even works with dotnet20sp1 alone - is wine transcendent or what?  8)
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-03-21 16:48:18
a quick question: i would like to update (overwrite) the codecs from cuetools 2016 with the ones from 2017, will this work?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-03-21 16:51:33
a quick question: i would like to update (overwrite) the codecs from cuetools 2016 with the ones from 2017, will this work?
Sorry, no. Also settings are incompatible, so it's best to either remove user_profiles_enabled file to keep settings with the program.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-03-21 16:58:11
ok, i see, thanks.

i would like to stick with 2016 stable, any chance to make use of the latest flac version avaiable, then?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-03-22 13:54:37
No. But there's really no point. At this point in flac development, there aren't many improvements to be had.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-03-22 16:34:37
have you ever considered making cuetools more modular by using codec.exes that can be exchanged more easily? i guess there is good reasons how things are working out right now, but i believe a modular concept has its claim.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-03-22 16:39:15
First of all, it is. You can actually configure it to use an external command line encoder if you wish to do so.
I wouldn't recommend it. As i said, flac is very stable and there's really no point in updating it.
Personally i use cuetools built in encoder, because it provides better compression than official encoder.
If i didn't have that, i'd use builtin libFLAC version, because it's stable and using a .dll is faster and safer in some ways than using an external command line encoder.
But if for some reason i fail to grasp those two options don't appeal to you, go ahead and configure an external command line encoder.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-03-22 16:55:26
hey, no worries - it was more or less a kind of remembrance of the good old burrrn days :)

i loved the tool for its modularity, a very clean and simply way to update codecs (if you feel the need for).

i can live with an older flac version, but i would have upgraded if it is just a matter of copying over a file...
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: DJAd on 2018-03-22 17:36:03
i can live with an older flac version, but i would have upgraded if it is just a matter of copying over a file...

Same here. I'm still trying out CUETools and using 2.1.6 but am looking forward to 2.1.7 with updated FLAC.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ozz on 2018-03-26 08:05:53
hi
will there be support for musepack?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-03-31 14:37:09
i just tested cuetools 2.17 on a 64bit wineprefix (dotnet40 + vcrun2015 installed). when running libflac as encoder, i get the following warning:

exception: arithmetic operation resulted in an overflow

btw - cuetools encoder works, but it is very slow (50x) in comparison to libflac (170x on 2.16). is this the normal case (always used libflac)?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-03-31 15:05:46
will there be support for musepack?
It's probably possible to configure CUETools to use a command line musepack encoder.

i just tested cuetools 2.17 on a 64bit wineprefix (dotnet40 + vcrun2015 installed).
I'm afraid i never tested cuetools with Wine. Was cuetools encoder as slow in 2.1.6? Also, what compression levels are we talking about in both cases, because cuetools -5 often compresses as good as libFLAC -7.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2018-03-31 15:36:56
btw - cuetools encoder works, but it is very slow (50x) in comparison to libflac (170x on 2.16). is this the normal case (always used libflac)?
You have to realize that CUETools flake compresses as least as good as the generic flac encoder using the additional parameters e and p. The speed is great for its compression rate then. It is ~150x on a slightly OC'd 8700k at -8 btw.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-03-31 17:31:12
I'm afraid i never tested cuetools with Wine. Was cuetools encoder as slow in 2.1.6? Also, what compression levels are we talking about in both cases, because cuetools -5 often compresses as good as libFLAC -7.
no prob, just wanted to let you know there is problems with wine and ct 2.17.

regarding cuetools encoder, i left all to default values (-5). in 2.16, the speed is pretty much identical.

@wombat: thanks for clarifying. which level to choose then with cuetools, if i am looking for libflac -6 (cuetools -4)?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Wombat on 2018-03-31 18:05:44
Sorry, i don't have numbers for inbetween levels. I always used and therefore compared high compression settings.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-04-01 12:57:26
Sorry, i don't have numbers for inbetween levels. I always used and therefore compared high compression settings.
well, i tried with cuetools -4 so to be on par with libflac -6, but it did not get that much better. now it is 58x (2.16 & 2.17) vs 170x (2.16).
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-04-01 15:10:36
Thanks. Well, i'll blame Wine. It's a lot faster without it. Have you tried Mono?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-04-01 17:55:41
Thanks. Well, i'll blame Wine. It's a lot faster without it. Have you tried Mono?
no, i have not, but i'd be interrested to know as well. unfortunately, with mono, some tools refuse to work properly and you can not have both (dotnet + mono) in parallel.

in the end, it is just my wineprefix - ha! anyone on linux with the same results?

what is the speed of cuetools vs libflac on your win machine?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-04-01 19:31:22
Quick unscientific test on one small file:
Code: [Select]
Size       mode            speed
25,144,135 cuetools-8.flac 83.21x;
25,149,808 cuetools-7.flac 110.74x
25,153,336 cuetools-6.flac 122.28x
25,161,336 cuetools-5.flac 152.34x
25,172,183 cuetools-4.flac 172.86x
25,171,795 libFLAC-8.flac  161.39x
25,182,825 libFLAC-7.flac  222.90x
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sanskrit44 on 2018-04-02 07:17:04
thank you.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Ozz on 2018-04-05 19:03:18
will there be support for musepack?
It's probably possible to configure CUETools to use a command line musepack encoder.
Unable to select an extension to configure musepack
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-04-05 19:06:55
Oh right, sorry. Forgot i never got around to adding a button to register a new extension.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ssri on 2018-04-14 06:26:49
Wow, I've been running CUETools 2.1.5 in kvm (Linux VM) with XP for years. Running CUETools 2.1.6 under wine 3.0 on the same system is 7.5x faster (6 seconds vs 45 seconds) for a verify on the same album. Fortunately I did not encounter any crashes using wine, all the config screens worked fine. The font size is microscopically small on my 4K monitor though.
I'm seeing the same with Windows 10.  It appears that CUETools 2.1.6 does not follow DPI scaling I set.  Does anyone have any solutions?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ssri on 2018-05-06 02:41:18
Is CUETools having issues querying recently added albums from ctdb?

http://db.cuetools.net/?tocid=xlmbOkBcwfHM2CvMl990tuhd5TY-

When running verify:
Code: [Select]
[CUETools log; Date: 5/5/2018 6:38:02 PM; Version: 2.1.6]
[AccurateRip ID: 001681b5-00d1bdf6-960bb00c] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   99.8 [436F1A4D] [2933A9F6]          
 01   99.8 [F4F2AA2F] [5D9DCF21]   CRC32  
 02   99.8 [7044355F] [3E8D5529]   CRC32  
 03   99.8 [ECF0A1A8] [907B2025]   CRC32  
 04   99.8 [517F682D] [D8EBD158]   CRC32  
 05   99.8 [22D45D61] [4530D008]   CRC32  
 06   99.8 [3A3ED517] [0C7663F0]   CRC32  
 07   99.8 [598B0B27] [CDEDA38A]   CRC32  
 08   99.8 [4D7EE73F] [CA9905E1]   CRC32  
 09   99.8 [BED8E745] [4E9C0D9A]   CRC32  
 10   99.8 [3C97D910] [8E80C50D]   CRC32  
 11   99.8 [12BC2E1E] [EAC74562]   CRC32  
 12   99.8 [C1DDBF90] [D3D7D3D9]   CRC32

An older album verified just fine.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 2018-05-06 02:44:30
No, it looks like it didn't even try to query the database. You might have turned it off by mistake. It's the checkbox next to the icon of a CD with a red plus on it.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: ssri on 2018-05-07 04:25:30
No, it looks like it didn't even try to query the database. You might have turned it off by mistake. It's the checkbox next to the icon of a CD with a red plus on it.
Grrr, new install... my bad.  Thanx
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jasn on 2018-06-13 15:24:09
Greetings from a noob.  I've been using CueTools (ver 15) for awhile but lately receiving an "Exception: An Invalid Argument was supplied" error when trying to split files.  Might someone be able to point me towards a solution?  Using latest versions does not solve.

Thx
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-06-14 13:16:00
A little more information would help. You didn't even give a format for the input or output files.
FLACCL can throw this type of exception. Perhaps you changed the FLAC encoder?
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jasn on 2018-06-14 15:20:16
Thank you for responding korth.  Apparently it has something to do with my particular computer (running Win 10).  I've tried the same program, same cue file on a different LT (also Win 10) and it runs fine.  BTW I am using unaltered default settings and have had no problems until lately.

I will try to clean all evidence of CueTools out of my registry, restart and see if that cures the error.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: korth on 2018-06-14 16:01:22
If you're not running as portable, the settings file is in %appdata%\CUE Tools
Delete (or rename) while CUETools isn't running.
Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: jasn on 2018-06-14 18:45:52
Thank you again korth.  I'd tried everything with no luck, until I loaded it to a usb drive and it now works fine.  Whatever...it's good to have it working again.  :)

Title: Re: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Porcus on 2018-06-16 20:09:17
Just a suggestion "for consideration" (I don't really know if there is a "good" way of improving this) for the settings. It concerns all the places there are tagging-related options. If I open the preferences, I see

* One tab for "Tagging".
* One tab for AccurateRip. Therein, there is a choice to write AccurateRip tags or not.
* One Advanced tab, where several sections are tagging-relevant.

At least, why not rename the AccurateRip tab into "AccurateRip&CTDB" and put the "Write CTDB tags" into there? Typically, I either want information to be updated or I don't ...

(And there is enough room in the Tagging tab to put the first two "advanced" tagging preferences to the right - could have an "Advanced" heading.)
Title: Re: CUETools versions 1.9.5 through 2.1.5
Post by: korth on 2018-07-20 05:27:57
This thread is locked. Please use the new CUETools forum (https://hydrogenaud.io/index.php/board,74.0.html) area for comments, questions about usage or otherwise request assistance. See Read First: a few posting guidelines (https://hydrogenaud.io/index.php/topic,116264.0.html) before posting and for more information about where to make bug reports.