Hydrogenaudio Forums

CD-R and Audio Hardware => CD Hardware/Software => Topic started by: Gregory S. Chudov on 02 October, 2008, 07:26:13 AM

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 02 October, 2008, 07:26:13 AM
Please welcome, CUETools v2.1.4. (CUETools download page (http://www.cuetools.net/wiki/CUETools_Download)) or direct link: http://www.cuetools.net/install/CUETools_2.1.4.rar (http://www.cuetools.net/install/CUETools_2.1.4.rar)

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

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

IMPORTANT: .NET Framework 2.0 (SP2) (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.

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).
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Fandango on 03 October, 2008, 12:11:20 PM
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 03 October, 2008, 01:17:56 PM
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 03 October, 2008, 09:48:48 PM
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 04 October, 2008, 09:53:52 AM
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 04 October, 2008, 05:53:10 PM
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 04 October, 2008, 06:49:01 PM
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 04 October, 2008, 07:34:16 PM
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 05 October, 2008, 09:57:38 AM
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 05 October, 2008, 03:39:05 PM
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 05 October, 2008, 04:58:38 PM
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 05 October, 2008, 07:53:11 PM
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 06 October, 2008, 10:40:02 AM
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 06 October, 2008, 07:15:04 PM
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 06 October, 2008, 11:12:31 PM
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 07 October, 2008, 12:48:28 AM
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 07 October, 2008, 02:07:07 AM
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 07 October, 2008, 01:25:02 PM
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 07 October, 2008, 02:51:46 PM
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 07 October, 2008, 06:10:59 PM
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 07 October, 2008, 07:32:06 PM
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!:
(https://hydrogenaud.io/imgcache.php?id=4be93a7b3cbfc48e8f9641d7e4a69020" rel="cached" data-warn="External image, click to view at original size" data-url="http://img146.imageshack.us/img146/1756/tripleflacreport3ss9.th.png) (http://img146.imageshack.us/my.php?image=tripleflacreport3ss9.png)(https://hydrogenaud.io/imgcache.php?id=bc55035377eab0f001b65881685d1d9e" rel="cached" data-warn="External image, click to view at original size" data-url="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 07 October, 2008, 08:47:15 PM
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 08 October, 2008, 03:58:20 AM
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 08 October, 2008, 08:56:04 AM
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 08 October, 2008, 09:49:31 AM
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 08 October, 2008, 11:04:02 AM
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 08 October, 2008, 11:31:36 AM
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 08 October, 2008, 12:00:18 PM
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 08 October, 2008, 12:34:04 PM
@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 09 October, 2008, 03:35:30 PM
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 09 October, 2008, 08:24:26 PM
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 09 October, 2008, 11:01:01 PM
@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 10 October, 2008, 05:32:52 AM
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 10 October, 2008, 06:00:41 AM
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 10 October, 2008, 06:14:28 AM
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 10 October, 2008, 07:57:25 AM
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 10 October, 2008, 08:31:11 AM
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 10 October, 2008, 07:29:13 PM
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 11 October, 2008, 07:39:37 AM
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 11 October, 2008, 08:06:49 AM
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 11 October, 2008, 05:59:22 PM
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 11 October, 2008, 06:41:43 PM
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 11 October, 2008, 07:42:58 PM
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 11 October, 2008, 07:45:50 PM
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 12 October, 2008, 10:29:34 AM
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 12 October, 2008, 10:54:13 AM
I created a mockup to demonstrate my suggestion:

(https://hydrogenaud.io/imgcache.php?id=19b5be567b929306a6b2fb82ffda982f" rel="cached" data-warn="External image, click to view at original size" data-url="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 12 October, 2008, 11:33:43 AM

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 12 October, 2008, 02:47:48 PM
I thought this was pretty cool, it runs fine with Mono 2.0 in Ubuntu when compiled with only WAV support:

(https://hydrogenaud.io/imgcache.php?id=dd2e6136668cc120e5a6e6aa5607eb55" rel="cached" data-warn="External image, click to view at original size" data-url="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 12 October, 2008, 06:32:08 PM
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 12 October, 2008, 06:45:17 PM
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 13 October, 2008, 12:03:17 AM
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 13 October, 2008, 07:30:49 AM
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 13 October, 2008, 07:54:26 AM
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 13 October, 2008, 08:51:19 AM
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 13 October, 2008, 09:54:58 AM
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 13 October, 2008, 10:18:47 AM
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 13 October, 2008, 11:39:10 AM
*) 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 13 October, 2008, 12:23:28 PM
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 13 October, 2008, 12:42:33 PM
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 13 October, 2008, 10:25:51 PM
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 13 October, 2008, 10:29:35 PM
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 14 October, 2008, 01:47:12 PM
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 14 October, 2008, 02:30:50 PM
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 14 October, 2008, 05:07:01 PM
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 15 October, 2008, 01:06:02 AM
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 15 October, 2008, 04:58:11 AM

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 16 October, 2008, 02:14:28 PM

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 16 October, 2008, 03:47:27 PM
(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 16 October, 2008, 04:30:41 PM
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 16 October, 2008, 08:06:14 PM
(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 17 October, 2008, 02:13:59 PM
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 17 October, 2008, 08:43:56 PM
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 18 October, 2008, 10:20:51 AM
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 18 October, 2008, 07:29:42 PM
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 18 October, 2008, 10:02:59 PM
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 19 October, 2008, 04:41:06 AM
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 19 October, 2008, 04:53:52 AM
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 19 October, 2008, 06:45:09 AM
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 19 October, 2008, 07:28:37 AM

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 19 October, 2008, 07:44:48 AM
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 19 October, 2008, 09:02:12 AM
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 19 October, 2008, 09:50:34 AM
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 19 October, 2008, 10:34:46 AM
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 19 October, 2008, 11:43:49 AM
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 19 October, 2008, 02:09:37 PM
@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 20 October, 2008, 01:42:03 AM
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 20 October, 2008, 03:25:34 AM
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 20 October, 2008, 05:38:46 AM
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 20 October, 2008, 06:44:05 AM
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 20 October, 2008, 10:17:02 AM

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 22 October, 2008, 07:55:28 AM
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 22 October, 2008, 04:56:42 PM
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 22 October, 2008, 08:03:08 PM
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 23 October, 2008, 03:13:53 AM
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 23 October, 2008, 12:15:58 PM
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 23 October, 2008, 02:12:50 PM
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 23 October, 2008, 04:20:17 PM
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 25 October, 2008, 04:14:09 PM
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 26 October, 2008, 04:31:22 AM
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 26 October, 2008, 09:32:40 AM

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 26 October, 2008, 09:34:16 AM
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 27 October, 2008, 02:20:28 PM
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 09 November, 2008, 08:13:58 AM
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 09 November, 2008, 08:26:37 AM
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 09 November, 2008, 09:30:18 AM

** (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 10 November, 2008, 12:38:33 PM
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 10 November, 2008, 12:49:41 PM
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 10 November, 2008, 03:32:27 PM
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 11 November, 2008, 10:58:33 AM
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 11 November, 2008, 11:31:41 AM
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 11 November, 2008, 01:21:12 PM
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 11 November, 2008, 09:34:58 PM
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 12 November, 2008, 06:26:05 PM
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 12 November, 2008, 09:12:50 PM
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 13 November, 2008, 12:41:29 AM
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 13 November, 2008, 11:20:52 AM
::

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

::
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: greynol on 13 November, 2008, 11:39:33 AM
That doesn't affect AR checksums.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Quarck on 13 November, 2008, 12:04:59 PM
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 13 November, 2008, 02:59:17 PM
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 18 November, 2008, 10:15:22 AM
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 19 November, 2008, 07:41:42 AM
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 19 November, 2008, 12:15:26 PM
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 19 November, 2008, 07:21:39 PM
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 25 November, 2008, 07:19:27 AM
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 25 November, 2008, 07:34:01 AM
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 25 November, 2008, 09:51:19 PM
* 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 26 November, 2008, 08:04:49 AM
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 28 November, 2008, 09:34:53 AM
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 10 December, 2008, 02:21:49 AM
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 10 December, 2008, 07:24:53 AM
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 14 December, 2008, 11:48:16 PM
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:

(https://hydrogenaud.io/imgcache.php?id=c6d45daaffd81c3df2405285a52d2971" rel="cached" data-warn="External image, click to view at original size" data-url="http://pic.ipicture.ru/uploads/081215/oxRQUV3qdb.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 25 December, 2008, 08:52:39 PM
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 28 December, 2008, 07:29:45 AM
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 28 December, 2008, 02:35:32 PM
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 28 December, 2008, 02:58:37 PM
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 28 December, 2008, 03:52:29 PM
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 28 December, 2008, 05:49:38 PM
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 28 December, 2008, 09:55:07 PM
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 31 December, 2008, 07:24:32 PM
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 01 January, 2009, 08:37:26 AM
::

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 01 January, 2009, 11:46:43 AM
::

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 01 January, 2009, 12:46:54 PM
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 08 January, 2009, 01:27:49 PM
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 08 January, 2009, 04:59:15 PM
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 08 January, 2009, 08:20:55 PM
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 09 January, 2009, 02:07:22 AM
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 09 January, 2009, 04:21:17 AM
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 09 January, 2009, 07:53:17 AM
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 09 January, 2009, 01:06:15 PM
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 11 January, 2009, 07:11:30 AM
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 11 January, 2009, 10:39:51 AM
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 16 January, 2009, 01:55:47 PM
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 16 January, 2009, 02:58:40 PM
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 16 January, 2009, 03:06:43 PM

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 16 January, 2009, 05:22:47 PM
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 16 January, 2009, 11:04:02 PM
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 16 January, 2009, 11:12:27 PM
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 16 January, 2009, 11:18:53 PM
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 16 January, 2009, 11:21:43 PM
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 19 January, 2009, 07:27:06 PM
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 19 January, 2009, 08:21:04 PM
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 19 January, 2009, 11:57:12 PM
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 31 January, 2009, 01:13:52 PM
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 31 January, 2009, 02:45:18 PM
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 31 January, 2009, 07:19:58 PM
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 03 February, 2009, 04:04:39 PM
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 03 February, 2009, 04:10:20 PM
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 03 February, 2009, 04:46:53 PM
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 05 February, 2009, 12:26:10 PM
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 09 February, 2009, 12:05:04 PM
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 09 February, 2009, 12:37:48 PM
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 09 February, 2009, 01:45:51 PM
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 12 February, 2009, 01:14:22 PM
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 12 February, 2009, 01:28:58 PM
=================================================================
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 12 February, 2009, 03:03:39 PM
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 12 February, 2009, 03:09:06 PM
Use the "Own format" textbox.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 12 February, 2009, 06:17:28 PM
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 13 February, 2009, 01:08:57 PM
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 13 February, 2009, 01:14:56 PM
AFAICS it is taken from the system?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 13 February, 2009, 04:36:22 PM
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 13 February, 2009, 06:21:55 PM
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 14 February, 2009, 04:33:44 AM
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 14 February, 2009, 02:11:17 PM
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 14 February, 2009, 04:20:28 PM


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 17 February, 2009, 03:31:51 AM
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 17 February, 2009, 09:46:43 AM
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 17 February, 2009, 10:29:01 AM
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 17 February, 2009, 11:56:28 AM
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 17 February, 2009, 12:00:22 PM
Without nullsamples, I guess?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Steve Forte Rio on 17 February, 2009, 12:10:56 PM
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 17 February, 2009, 01:17:40 PM
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 17 February, 2009, 01:37:34 PM
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 17 February, 2009, 01:49:27 PM
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 17 February, 2009, 02:19:18 PM
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 17 February, 2009, 02:37:13 PM
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 18 February, 2009, 03:59:05 AM
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 18 February, 2009, 09:38:04 AM
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 18 February, 2009, 11:20:50 AM
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 19 February, 2009, 06:02:50 AM
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 19 February, 2009, 06:09:48 AM
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 19 February, 2009, 06:13:35 AM
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 19 February, 2009, 09:34:57 AM
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 19 February, 2009, 09:40:03 AM
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 19 February, 2009, 11:43:14 PM
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 20 February, 2009, 12:17:56 PM
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 20 February, 2009, 08:13:04 PM
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 22 February, 2009, 11:18:32 PM
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 23 February, 2009, 12:32:38 AM
Thanks for the update Gregory!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: glebe on 23 February, 2009, 04:17:12 AM
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 28 February, 2009, 03:19:03 PM
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 28 February, 2009, 03:22:25 PM
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 28 February, 2009, 03:30:32 PM
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 28 February, 2009, 03:33:34 PM
Ah, another Winampian?
Sorry then.

Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 28 February, 2009, 05:13:40 PM
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 01 March, 2009, 10:41:50 AM
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 01 March, 2009, 11:24:09 AM
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 01 March, 2009, 12:16:16 PM
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 01 March, 2009, 06:16:18 PM
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:

(https://hydrogenaud.io/imgcache.php?id=7490881cc272cb1f076014dbbdb8730b" rel="cached" data-warn="External image, click to view at original size" data-url="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 01 March, 2009, 09:24:37 PM
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 02 March, 2009, 02:27:16 AM
@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 02 March, 2009, 09:51:46 AM
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 02 March, 2009, 10:09:19 AM
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 02 March, 2009, 11:45:16 AM
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 02 March, 2009, 12:13:38 PM
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 04 March, 2009, 04:16:32 PM
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 05 March, 2009, 09:16:34 AM
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 05 March, 2009, 10:57:37 AM
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 05 March, 2009, 12:47:59 PM
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 05 March, 2009, 02:17:15 PM
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 05 March, 2009, 06:36:29 PM
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 07 March, 2009, 05:01:29 AM
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 08 March, 2009, 05:52:36 PM
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 08 March, 2009, 06:02:24 PM
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 08 March, 2009, 06:16:18 PM
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 08 March, 2009, 06:56:00 PM
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 08 March, 2009, 07:03:55 PM
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 08 March, 2009, 07:28:18 PM
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 08 March, 2009, 07:38:13 PM
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 09 March, 2009, 04:43:26 PM
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 09 March, 2009, 04:45:02 PM
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 10 March, 2009, 02:07:39 AM
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 10 March, 2009, 07:23:49 AM
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 10 March, 2009, 07:30:30 AM
..., 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 13 March, 2009, 10:44:04 AM
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 13 March, 2009, 03:38:15 PM
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 22 March, 2009, 01:11:56 PM
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 22 March, 2009, 01:14:43 PM
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 22 March, 2009, 01:39:43 PM
 ... 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 22 March, 2009, 01:40:17 PM
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 22 March, 2009, 01:44:32 PM
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 22 March, 2009, 01:45:07 PM
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 22 March, 2009, 02:02:13 PM
When 2.0x64 will be available?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 22 March, 2009, 02:07:15 PM
When 2.0x64 will be available?

Done.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 22 March, 2009, 02:10:56 PM
Oh, thank you.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: acmodeu on 22 March, 2009, 02:17:37 PM
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 22 March, 2009, 02:20:48 PM
Hmm, i will look into it.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Scidd0w on 23 March, 2009, 05:17:29 AM
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 23 March, 2009, 10:57:38 AM
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 23 March, 2009, 11:30:28 AM
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 23 March, 2009, 01:16:14 PM
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 23 March, 2009, 01:22:04 PM
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 23 March, 2009, 01:31:43 PM
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 23 March, 2009, 01:56:24 PM
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 23 March, 2009, 05:39:06 PM
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 24 March, 2009, 05:54:40 AM
...
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 24 March, 2009, 06:12:17 AM
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 24 March, 2009, 07:00:14 AM
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 24 March, 2009, 07:15:59 AM
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 25 March, 2009, 02:31:36 PM
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 25 March, 2009, 02:37:36 PM
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 25 March, 2009, 02:42:47 PM
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 26 March, 2009, 07:37:57 AM
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 26 March, 2009, 11:28:10 AM
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 26 March, 2009, 01:11:09 PM
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 26 March, 2009, 02:37:06 PM
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 26 March, 2009, 02:46:04 PM
It doesn't work intuitively, at least...
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 26 March, 2009, 03:27:41 PM
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 26 March, 2009, 03:29:43 PM
This is the first option in advanced settings.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Alex B on 26 March, 2009, 04:45:17 PM
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 26 March, 2009, 07:29:06 PM
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.

(https://hydrogenaud.io/imgcache.php?id=c86e100ae986f02e21b895e6d5851b0b" rel="cached" data-warn="External image, click to view at original size" data-url="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 27 March, 2009, 06:00:05 AM
...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 27 March, 2009, 03:41:44 PM
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 28 March, 2009, 05:35:22 AM
Always get error message: SHGetFolderLocation failed:

(https://hydrogenaud.io/imgcache.php?id=ff36a910b00a039d7e5c2ddbba3da49c" rel="cached" data-warn="External image, click to view at original size" data-url="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 28 March, 2009, 05:43:33 AM
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 28 March, 2009, 11:38:18 AM
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 28 March, 2009, 01:19:38 PM
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 28 March, 2009, 02:21:55 PM
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 28 March, 2009, 02:43:55 PM
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 28 March, 2009, 03:05:16 PM
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 28 March, 2009, 03:13:57 PM
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 28 March, 2009, 03:17:34 PM
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 28 March, 2009, 03:50:01 PM
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 28 March, 2009, 03:55:24 PM
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 28 March, 2009, 03:59:32 PM
Confirmed! Working with version 2.01.
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 28 March, 2009, 04:12:48 PM
"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 28 March, 2009, 04:53:58 PM
"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 28 March, 2009, 05:21:25 PM
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 29 March, 2009, 02:11:13 AM
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 29 March, 2009, 02:30:02 AM
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 29 March, 2009, 06:17:13 AM
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 29 March, 2009, 06:47:25 AM
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 29 March, 2009, 04:39:27 PM
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 30 March, 2009, 10:10:49 AM
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 31 March, 2009, 05:10:18 AM
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 31 March, 2009, 07:51:28 PM
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 31 March, 2009, 08:13:14 PM
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 31 March, 2009, 08:16:48 PM
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 31 March, 2009, 08:19:08 PM
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 31 March, 2009, 08:29:40 PM
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 31 March, 2009, 08:41:23 PM
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 31 March, 2009, 09:18:11 PM
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 31 March, 2009, 09:26:54 PM
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 31 March, 2009, 09:29:29 PM
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 31 March, 2009, 09:43:41 PM
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 31 March, 2009, 09:51:16 PM
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 31 March, 2009, 10:10:13 PM
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 31 March, 2009, 10:18:58 PM
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 31 March, 2009, 10:26:56 PM
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 01 April, 2009, 12:27:08 AM
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 01 April, 2009, 12:53:51 AM
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 01 April, 2009, 01:14:13 AM
> 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 01 April, 2009, 02:22:25 AM
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 01 April, 2009, 06:09:15 AM
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 03 April, 2009, 05:11:44 AM
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 04 April, 2009, 01:26:56 AM
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 04 April, 2009, 06:54:54 AM
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 04 April, 2009, 09:24:11 AM
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 04 April, 2009, 04:34:21 PM
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 05 April, 2009, 04:20:49 AM
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 05 April, 2009, 05:02:38 AM
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 05 April, 2009, 05:15:01 AM
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 05 April, 2009, 05:40:23 AM
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 05 April, 2009, 05:51:37 AM
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 05 April, 2009, 06:29:42 AM
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 05 April, 2009, 06:39:08 AM
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 05 April, 2009, 07:20:24 AM
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 05 April, 2009, 07:25:55 AM
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 05 April, 2009, 07:32:12 AM
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 05 April, 2009, 07:50:46 AM
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 05 April, 2009, 08:00:56 AM
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 05 April, 2009, 08:53:14 AM
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 05 April, 2009, 11:51:30 AM
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 05 April, 2009, 12:19:24 PM
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 05 April, 2009, 02:12:22 PM
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 05 April, 2009, 04:42:37 PM
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 06 April, 2009, 03:14:27 PM
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 07 April, 2009, 02:23:01 PM
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 07 April, 2009, 02:53:21 PM
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 07 April, 2009, 04:37:18 PM
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 08 April, 2009, 02:41:56 PM
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 10 April, 2009, 04:24:56 PM
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 14 April, 2009, 03:40:32 PM
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 16 April, 2009, 04:43:20 PM
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 16 April, 2009, 05:51:58 PM
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 16 April, 2009, 05:55:34 PM
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 17 April, 2009, 04:11:42 AM
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 20 April, 2009, 10:49:20 AM
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 20 April, 2009, 10:56:14 AM
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 20 April, 2009, 11:44:32 AM
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 24 April, 2009, 05:35:05 AM
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 24 April, 2009, 06:13:04 AM
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 24 April, 2009, 07:03:29 AM
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 24 April, 2009, 08:14:56 AM
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 24 April, 2009, 11:05:09 AM
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 24 April, 2009, 09:16:11 PM
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 26 April, 2009, 06:03:37 PM
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 26 April, 2009, 06:52:02 PM
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 27 April, 2009, 06:29:11 PM
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 30 April, 2009, 11:16:34 PM
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 01 May, 2009, 10:57:09 AM
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 01 May, 2009, 11:01:32 AM
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 01 May, 2009, 11:29:50 AM
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 01 May, 2009, 11:49:13 AM
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 01 May, 2009, 12:53:16 PM
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 01 May, 2009, 01:42:54 PM
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 01 May, 2009, 02:03:34 PM
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 01 May, 2009, 02:10:36 PM
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 01 May, 2009, 02:21:01 PM
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 02 May, 2009, 04:04:11 AM
'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 02 May, 2009, 04:06:41 AM
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 02 May, 2009, 11:39:36 AM
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 02 May, 2009, 12:32:13 PM
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 03 May, 2009, 03:45:57 AM
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 03 May, 2009, 05:21:56 AM
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 03 May, 2009, 06:21:09 AM
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 03 May, 2009, 06:26:18 AM
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:

(https://hydrogenaud.io/imgcache.php?id=a1dfdd08239d11adb350eb7dca68d607" rel="cached" data-warn="External image, click to view at original size" data-url="http://i224.photobucket.com/albums/dd212/AB2K/ha/cuetools.png)

(https://hydrogenaud.io/imgcache.php?id=3cb4d12a7ce993e284ce9a04a08a3e3e" rel="cached" data-warn="External image, click to view at original size" data-url="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 03 May, 2009, 06:40:23 AM
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 03 May, 2009, 10:31:59 AM
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 03 May, 2009, 02:51:54 PM
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 03 May, 2009, 11:38:23 PM
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 04 May, 2009, 02:34:50 AM
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 05 May, 2009, 08:47:38 PM
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 06 May, 2009, 08:03:48 AM
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 06 May, 2009, 09:41:30 AM
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 06 May, 2009, 09:53:49 AM
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 06 May, 2009, 11:08:22 AM
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 06 May, 2009, 11:15:53 AM
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 06 May, 2009, 11:24:33 AM
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 08 May, 2009, 06:47:37 AM
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 08 May, 2009, 09:16:08 AM
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 08 May, 2009, 02:28:16 PM
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 09 May, 2009, 01:11:44 AM
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 10 May, 2009, 08:33:36 PM
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 11 May, 2009, 06:35:57 AM
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 12 May, 2009, 08:35:21 PM
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 12 May, 2009, 09:26:12 PM
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 12 May, 2009, 09:36:06 PM
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 15 May, 2009, 10:52:23 PM
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:

(https://hydrogenaud.io/imgcache.php?id=e380e9317acf8ed6f21cdedcd73b91c6" rel="cached" data-warn="External image, click to view at original size" data-url="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 17 May, 2009, 08:42:23 AM
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 17 May, 2009, 09:57:27 AM
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 17 May, 2009, 10:00:35 AM
Here is a screenshot of the 2nd (even less annoying than the first) displaying bug at 125%.

(https://hydrogenaud.io/imgcache.php?id=1551ca2196650c6a924370ae2476c3df" rel="cached" data-warn="External image, click to view at original size" data-url="http://img196.imageshack.us/img196/6039/clipboard01k.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: NightOwl on 17 May, 2009, 12:33:09 PM
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 17 May, 2009, 05:14:59 PM
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 17 May, 2009, 06:07:30 PM
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 17 May, 2009, 06:41:19 PM
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 18 May, 2009, 10:39:43 AM
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.

(https://hydrogenaud.io/imgcache.php?id=a7945f85093908de72aab79d5cb72278" rel="cached" data-warn="External image, click to view at original size" data-url="http://img35.imageshack.us/img35/8991/cuetools.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 18 May, 2009, 10:45:14 AM
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 20 May, 2009, 05:18:46 PM
Watching at the accuraterip logo:
(https://hydrogenaud.io/imgcache.php?id=2b2a7822a0f70c5cccfbe89b8162f1c7" rel="cached" data-warn="External image, click to view at original size" data-url="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:
(https://hydrogenaud.io/imgcache.php?id=9b4198cf116ef443a57007b718480a82" rel="cached" data-warn="External image, click to view at original size" data-url="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 21 May, 2009, 03:34:16 AM
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 28 May, 2009, 08:57:47 AM
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 29 May, 2009, 07:15:27 PM
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 31 May, 2009, 03:36:40 PM
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 02 June, 2009, 08:45:59 AM
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 02 June, 2009, 08:56:11 AM
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 02 June, 2009, 09:30:23 AM
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 02 June, 2009, 10:04:47 AM
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 02 June, 2009, 11:21:46 AM
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 02 June, 2009, 01:46:37 PM
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 04 June, 2009, 12:12:52 PM
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 04 June, 2009, 12:24:49 PM
Did you try setting "CUE Style" to "Gaps Appended"?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Jayrcee on 05 June, 2009, 01:11:45 PM
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 05 June, 2009, 01:29:52 PM
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 05 June, 2009, 04:58:07 PM
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 14 June, 2009, 03:35:11 PM
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 15 June, 2009, 03:54:52 AM
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 16 June, 2009, 04:56:07 AM
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 16 June, 2009, 05:09:49 AM
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 16 June, 2009, 05:17:24 AM
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 16 June, 2009, 06:27:24 AM
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 16 June, 2009, 09:38:16 AM
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 16 June, 2009, 06:30:41 PM
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 18 June, 2009, 01:44:33 PM
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 18 June, 2009, 01:51:34 PM
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 18 June, 2009, 02:05:06 PM
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 18 June, 2009, 02:14:03 PM
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 21 June, 2009, 03:36:34 AM
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 21 June, 2009, 03:42:07 AM
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 22 June, 2009, 01:40:56 PM
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 22 June, 2009, 08:17:34 PM
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 22 June, 2009, 08:36:44 PM
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 23 June, 2009, 06:17:39 AM
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 23 June, 2009, 06:26:12 AM
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 23 June, 2009, 05:32:46 PM
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 24 June, 2009, 03:15:18 PM
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 24 June, 2009, 03:17:52 PM
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 24 June, 2009, 03:31:24 PM
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 24 June, 2009, 03:41:06 PM
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 24 June, 2009, 03:43:54 PM
I see. 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: tuxman on 24 June, 2009, 03:52:41 PM
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 24 June, 2009, 03:55:54 PM
Uh oh 
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 24 June, 2009, 07:38:10 PM
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 25 June, 2009, 03:10:42 AM
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 25 June, 2009, 03:53:50 AM
Hi!

Can U pls handle the resolution issue. It's really annoying:

(https://hydrogenaud.io/imgcache.php?id=7d608dd361ba02274533cd6600034647" rel="cached" data-warn="External image, click to view at original size" data-url="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 25 June, 2009, 05:20:32 AM
Large fonts?
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Gregory S. Chudov on 25 June, 2009, 06:20:30 AM
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 25 June, 2009, 07:02:36 AM
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 25 June, 2009, 09:13:00 AM
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 25 June, 2009, 10:02:26 AM
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 25 June, 2009, 01:31:31 PM
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 26 June, 2009, 12:54:41 AM
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 26 June, 2009, 04:22:20 AM
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 26 June, 2009, 04:29:36 AM
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 26 June, 2009, 04:36:40 AM
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 27 June, 2009, 06:43:49 AM
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)



THNX. It's perfect now!!!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Akkurat on 27 June, 2009, 07:34:35 AM
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 27 June, 2009, 07:59:30 AM
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 27 June, 2009, 09:16:46 AM
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 27 June, 2009, 10:28:53 AM
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 27 June, 2009, 03:15:43 PM
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 27 June, 2009, 04:57:05 PM
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 29 June, 2009, 10:30:34 AM
I still use v2.02a because of the display bug with 125% font which has get worst in 2.03

(https://hydrogenaud.io/imgcache.php?id=ee9990473488b8bc5b8043c21391d999" rel="cached" data-warn="External image, click to view at original size" data-url="http://img209.imageshack.us/img209/3303/clipboard01prr.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: No Fun on 29 June, 2009, 03:09:26 PM
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 29 June, 2009, 04:11:46 PM
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)

(https://hydrogenaud.io/imgcache.php?id=5c394de704a79c77b61e7aaaa3ccab63" rel="cached" data-warn="External image, click to view at original size" data-url="http://img199.imageshack.us/img199/3946/clipboard01mmg.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: odyssey on 30 June, 2009, 11:21:59 AM
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 30 June, 2009, 12:34:18 PM
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)
(https://hydrogenaud.io/imgcache.php?id=f0947b4e872bf15425d13e8cb82f38fc" rel="cached" data-warn="External image, click to view at original size" data-url="http://img29.imageshack.us/img29/9028/clipboard01jyf.jpg)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Tigerman on 05 July, 2009, 03:59:40 AM
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 05 July, 2009, 04:08:05 AM
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 05 July, 2009, 01:11:04 PM
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 05 July, 2009, 04:24:25 PM
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 05 July, 2009, 05:24:37 PM
> 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 05 July, 2009, 08:26:19 PM
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 07 July, 2009, 10:55:53 PM
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 08 July, 2009, 03:58:58 AM
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 08 July, 2009, 04:01:50 AM
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 08 July, 2009, 12:50:48 PM
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 08 July, 2009, 01:06:34 PM
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 09 July, 2009, 08:43:35 AM
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 10 July, 2009, 09:53:06 AM
(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 10 July, 2009, 10:30:36 AM
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 10 July, 2009, 12:16:51 PM
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 10 July, 2009, 01:42:06 PM
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 10 July, 2009, 01:44:13 PM
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 10 July, 2009, 01:47:39 PM
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 10 July, 2009, 04:23:48 PM
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 10 July, 2009, 04:43:15 PM
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 10 July, 2009, 06:01:21 PM
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 10 July, 2009, 06:19:59 PM
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 10 July, 2009, 06:57:08 PM
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 10 July, 2009, 08:10:12 PM
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 12 July, 2009, 07:35:04 AM
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 12 July, 2009, 10:14:21 AM
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 12 July, 2009, 10:21:01 AM
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 12 July, 2009, 12:28:40 PM
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 12 July, 2009, 01:31:53 PM
> 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 12 July, 2009, 05:13:01 PM
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 13 July, 2009, 10:14:04 PM
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 14 July, 2009, 03:17:51 AM
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 14 July, 2009, 07:02:36 PM
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 14 July, 2009, 07:25:22 PM
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 19 July, 2009, 05:34:34 PM
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 19 July, 2009, 05:51:29 PM
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 19 July, 2009, 09:46:44 PM
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 20 July, 2009, 12:53:03 AM
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 20 July, 2009, 05:54:25 AM
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 21 July, 2009, 01:10:46 AM
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 21 July, 2009, 02:58:07 PM
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 21 July, 2009, 10:58:34 PM
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 23 July, 2009, 04:53:36 AM
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 27 July, 2009, 10:13:26 AM
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 27 July, 2009, 10:17:51 AM
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 27 July, 2009, 10:51:10 AM
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 27 July, 2009, 10:57:09 AM
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 27 July, 2009, 10:57:57 AM
@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 27 July, 2009, 11:04:55 AM
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 28 July, 2009, 07:27:59 AM
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 01 August, 2009, 12:43:47 AM
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 01 August, 2009, 02:23:37 AM
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 01 August, 2009, 01:37:08 PM
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 01 August, 2009, 02:03:20 PM
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 03 August, 2009, 08:43:11 AM
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 06 August, 2009, 09:29:36 AM
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 06 August, 2009, 09:34:36 AM
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 06 August, 2009, 10:02:02 AM
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 06 August, 2009, 10:57:06 AM
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 06 August, 2009, 01:34:10 PM
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 06 August, 2009, 05:47:47 PM
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):

(https://hydrogenaud.io/imgcache.php?id=61f80d6f262883c96e18c58d7cbb6c5d" rel="cached" data-warn="External image, click to view at original size" data-url="http://img197.imageshack.us/img197/106/clipboard01xfv.png)

Things get even worst when I select the convert mode:

(https://hydrogenaud.io/imgcache.php?id=11cc23c679f82b2226d6c1640359f22e" rel="cached" data-warn="External image, click to view at original size" data-url="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 06 August, 2009, 09:41:20 PM
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).

(https://hydrogenaud.io/imgcache.php?id=190166e15afb041c06f005573d8ce9cf" rel="cached" data-warn="External image, click to view at original size" data-url="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 06 August, 2009, 10:47:04 PM
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 07 August, 2009, 12:04:53 AM
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:

(https://hydrogenaud.io/imgcache.php?id=46d0668a66d4292435793a4e119c7b10" rel="cached" data-warn="External image, click to view at original size" data-url="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 07 August, 2009, 12:20:44 AM
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 07 August, 2009, 01:23:21 AM
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 07 August, 2009, 01:27:36 AM
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 07 August, 2009, 04:43:12 AM
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 07 August, 2009, 05:05:06 AM
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 07 August, 2009, 06:07:28 AM
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 07 August, 2009, 07:41:08 AM
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 07 August, 2009, 09:07:26 AM
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 07 August, 2009, 12:47:26 PM
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:
(https://hydrogenaud.io/imgcache.php?id=a993b2559ec94d7a416bb6135dbbf62f" rel="cached" data-warn="External image, click to view at original size" data-url="http://img210.imageshack.us/img210/6475/clipboard01c.png)
Radio Buttons fixed:
(https://hydrogenaud.io/imgcache.php?id=d33b9e5292c6582f38cb7a01528867d0" rel="cached" data-warn="External image, click to view at original size" data-url="http://img210.imageshack.us/img210/9366/clipboard02t.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 07 August, 2009, 01:43:24 PM
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
(https://hydrogenaud.io/imgcache.php?id=8b22f2d1addc5da2cdb58b7be7f4bb61" rel="cached" data-warn="External image, click to view at original size" data-url="http://img411.imageshack.us/img411/583/clipboard01xgc.png)

V2.04 120% Fonts=No More Bugs
(https://hydrogenaud.io/imgcache.php?id=6fd2ed9e3c9e18a6d642f1062d9ad37f" rel="cached" data-warn="External image, click to view at original size" data-url="http://img411.imageshack.us/img411/229/clipboard01a.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: juest on 07 August, 2009, 02:42:54 PM
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 07 August, 2009, 03:33:22 PM
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 07 August, 2009, 06:36:16 PM
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 07 August, 2009, 06:52:22 PM
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 07 August, 2009, 06:59:25 PM
despite some minor bugs

Report them!
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: sauvage78 on 07 August, 2009, 07:08:17 PM
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 08 August, 2009, 03:09:44 AM
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 08 August, 2009, 08:02:39 PM
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 10 August, 2009, 04:39:26 AM
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 10 August, 2009, 08:51:43 AM
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 11 August, 2009, 05:11:39 AM
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 11 August, 2009, 10:47:39 AM
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 11 August, 2009, 11:16:37 PM
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 11 August, 2009, 11:49:39 PM
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 12 August, 2009, 12:47:59 AM
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 12 August, 2009, 02:56:34 AM
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 12 August, 2009, 03:05:25 AM
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:

(https://hydrogenaud.io/imgcache.php?id=dc6f09edef4382a6c405be7f63af26ca" rel="cached" data-warn="External image, click to view at original size" data-url="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 12 August, 2009, 03:34:11 AM
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 12 August, 2009, 05:37:42 AM
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:
(https://hydrogenaud.io/imgcache.php?id=c98a5441038c64e3eef7f0987f93ddf8" rel="cached" data-warn="External image, click to view at original size" data-url="http://img263.imageshack.us/img263/9265/clipboard01ak.png)
Title: CUETools versions 1.9.5 through 2.1.5 (current)
Post by: Chinch on 12 August, 2009, 09:38:29 AM
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 12 August, 2009, 11:43:43 AM
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 12 August, 2009, 01:42:47 PM
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 12 August, 2009, 03:41:46 PM
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 12 August, 2009, 04:34:58 PM
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 12 August, 2009, 10:09:14 PM
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 14 August, 2009, 07:14:14 AM
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 14 August, 2009, 07:39:35 AM
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 14 August, 2009, 07:46:02 AM
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 14 August, 2009, 07:46:43 AM
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 14 August, 2009, 08:02:15 AM
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 14 August, 2009, 08:02:22 AM
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 14 August, 2009, 08:08:14 AM
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 14 August, 2009, 08:08:17 AM
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 14 August, 2009, 08:20:28 AM
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 14 August, 2009, 08:39:25 AM
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 16 August, 2009, 10:26:02 AM
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 16 August, 2009, 11:19:50 AM
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 16 August, 2009, 11:58:50 AM
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 16 August, 2009, 12:12:57 PM
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 16 August, 2009, 01:13:57 PM
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 16 August, 2009, 01:18:10 PM
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 16 August, 2009, 01:26:50 PM
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 16 August, 2009, 02:19:19 PM
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 16 August, 2009, 03:04:57 PM
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 16 August, 2009, 03:07:53 PM
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 16 August, 2009, 03:38:33 PM
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 16 August, 2009, 03:45:40 PM
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 16 August, 2009, 03:46:56 PM
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 16 August, 2009, 04:04:28 PM
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 16 August, 2009, 04:13:55 PM
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 16 August, 2009, 04:22:33 PM
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 16 August, 2009, 09:50:27 PM
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 16 August, 2009, 10:24:40 PM
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 17 August, 2009, 01:41:04 AM
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 17 August, 2009, 05:55:41 AM
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 17 August, 2009, 07:23:08 AM
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 17 August, 2009, 09:42:14 AM
@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 17 August, 2009, 10:12:32 AM
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 17 August, 2009, 01:04:37 PM
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 17 August, 2009, 01:40:02 PM
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 19 August, 2009, 05:35:54 PM
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 19 August, 2009, 09:52:12 PM
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 20 August, 2009, 12:00:39 PM
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 22 August, 2009, 01:40:03 PM
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 22 August, 2009, 04:48:44 PM
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