Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUETools versions 1.9.5 through 2.1.6 (Read 1917098 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #725 –
Quote from: sauvage78 on
Quote
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
True
No, I gave an example demonstrating that this assertion is false.

Quote from: sauvage78 on
As long as you cut right in the middle of silence between two song then the offset will not really matter as the CRC will still be the same & match.
This is only true for a specific modification to the CRC calculation that can be implemented by EAC which basically strips any data with zero amplitude from either the left or right channel.  It is not the case for AR hashes or the standard CRC.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #726 –
Quote from: Chinch on
went into a lot more detail that i planned there..... aaah! just trying to help you out, my friend.  these can be tough concepts to learn, and i'm still learning, myself.

Ah, then I'd start by researching EFM and CIRC since your example of the laser positioning was pretty far off the mark, but to your credit you did a good job demonstrating what an offset is.  You might find this interesting as well:
http://club.myce.com/f52/offsets-handling-...channel-111913/

Why you brought up sector boundaries is still a mystery to me though.  In other words, this is complete nonsense:
Quote from: Chinch on
so that may be an example of how an offset could screw with things. this would really only apply to a live/gapless CD that is extracted to multiple files, and then a method of gap handling is chosen. this is one reason why i choose to rip my CDs in SINGLE WAV mode... therefore it is 1 WAV file, not WAV files that are going to be rejoined based on sectors and cue times.even if the offset were off a bit, there wouldn't be any of this zero filling causing pops or clicks... since there is no partitioning of the original data (other than at a super low level).

Quote from: Chinch on
you are right off the bat eliminating extra WAV headers, etc... possibly modified or filled data (depending on how the program handles a junction or split)
Could you please cite a program that doesn't join wave files correctly?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #727 –
I correct myself:
Quote
As long as you cut right in the middle of silence between two song then the offset will not really matter as the CRC will still be the same & match if you fix the offset.
Indeed if you don't fix the offset the CRC don't match as displayed within the accuraterip log.

It's hard to have the last word with Greynol  I thought he would kill me for suggesting to newbies to interpret the offset as a shift of splitpoints, that why I used the red for my note.

Edit: For the first point, your exemple is rather a temporary exception. As far as I understund how AR works, it is likely to be purged sooner or later when the drive become more popular or when a 2nd ripper rip the same CD & disagree. The normal behavior is that AR wants submission with the right offset correction.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #728 –
Naw, while I don't believe in correcting offsets simply so that they match the AR database and sometimes have a hard time with your English (I sometimes have a hard time even with my own English and it's my native language), I think your contributions to this topic have been quite good.  I've tried to keep an eye out for this thread, especially when it comes to people giving advice.  In the case of Chinch, much has been very good.  The advice that drew my sharpest criticism was the FUD over ripping to individual tracks.

Noting your edit, yes, I think you're right, though I don't know how long "temporary" might be.  I don't know how often the database is purged of questionable results.  I don't recall that it was very often.  Oh yeah, but if it's a sole entry without matches, it will be bumped once another entry hits the database.  IIRC, neither entry will then show until either of them gets a match from another submission with a unique user id.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #729 –
Quote from: sauvage78 on
Completely off-topic but is it just me or Gregory S. Chudov left the boat since he started to code for fake & flacuda ? CUETools is much more interesting piece of software IMHO.

CUETools is interesting, but there's not much left to be done here. I'm always more excited by doing something new, besides i'm a bit busy at work currently.

There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc. Thanks for ideas and suggestions, i will at least consider them.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #730 –
Hi Greg.

Actually the thing that I miss the most is a "fix offset only if the actual offset is not the most popular in database" mode, because actually it recodes everything blindly even if the result would end in the exact same encode.
More generally a "fix offset only if it actually really fixes something & skip when it doesn't" mode would made me save a lot of time not re-encoding twice a rip that is already with the most popular offset in the database. This would made me save time, money (energy) & wasted temporary HDD space.
This would just be as usefull IMHO as the actual "verify only if found" ... I am basically asking for a "fix offset only if fixable" mode. For someone who would use it, the benefit is comparable between the two modes.
I understand that people who don't fix offset will find this useless, but personnaly as I fix offset to make my accurip logs shorter, I find that this is really something missing.
I already asked for it & you told me to script it ... I wish I could ...

Also a "brute force attack" testing systematically all possible time length on data track would be usefull IMHO if it doesn't stress the database too much. Doing it manually is a pain & I have plenty of rips with old logs that don't include the data track length.
... and don't tell me to insert the CD in my drive ... when I could, I already did it

In the same way of thinking, a "brute force attack" on pre-gap with length 00:01 to say 00:59 would be interesting because I noticed that when you add a pre-gap of 00:32 or 00:33 (by far the most usual value) to some rips that are not present in database without pre-gap then if you're lucky you can fall on a set of matching CRC ... it happened to me several times (around ten times so far) so this is not unusual. It's just another kind pressing, just like there can be an offset difference, there can be a pre-gap difference & actually we do as if these pressings didn't exist.

Also a CD can have several value for the data track length ... don't ask me why it happened to me once when checking length manually & I think I recall it was a Pink Floyd CD ... the first set of CRC that I fall on had low confidency which was suspect for a Pink Floyd CD so I continued to check lenght & I finally falled on a very high confidency result. If I would have been lazy or non-suspect I would have stopped at after finding the first set of CRC. I guess it is far rarer than with artificially added pre-gap. But it happens ...

Then there is plenty of possible cosmetic fix/enhancements that would made the use of cuetools nicer ... if you want a TODO list I am sure I can create one as long as my arm

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #731 –
Hey guys,

it's me again with another question. I've been doing some tests with CUETools regarding dummy cue sheets.

I have ripped an album to 1 flac file per track + cue.
Now I converted it to wavpack using CUETools two times.

First I had the original cue file in the directory where the flac files are.
When I converted it everything was fine. Accurately ripped.

Code: [Select]
REM ACCURATERIPID 002d23b1-0288f713-0410be13
REM GENRE "Grunge"
REM DATE 2007
REM DISCID 0410BE13
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Foo Fighters"
TITLE "The Colour And The Shape"
FILE "The Colour And The Shape.wv" WAVE
  TRACK 01 AUDIO
    TITLE "Doll"
    PERFORMER "Foo Fighters"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Monkey Wrench"
    PERFORMER "Foo Fighters"
    INDEX 00 01:24:13
    INDEX 01 01:24:17
  TRACK 03 AUDIO
    TITLE "Hey, Johnny Park!"
    PERFORMER "Foo Fighters"
    INDEX 01 05:15:49
  TRACK 04 AUDIO
    TITLE "My Poor Brain"
    PERFORMER "Foo Fighters"
    INDEX 01 09:24:06
  TRACK 05 AUDIO
    TITLE "Wind Up"
    PERFORMER "Foo Fighters"
    INDEX 01 12:57:38
  TRACK 06 AUDIO
    TITLE "Up In Arms"
    PERFORMER "Foo Fighters"
    INDEX 00 15:28:36
    INDEX 01 15:29:31
  TRACK 07 AUDIO
    TITLE "My Hero"
    PERFORMER "Foo Fighters"
    INDEX 00 17:44:64
    INDEX 01 17:45:16
  TRACK 08 AUDIO
    TITLE "See You"
    PERFORMER "Foo Fighters"
    INDEX 01 22:05:01
  TRACK 09 AUDIO
    TITLE "Enough Space"
    PERFORMER "Foo Fighters"
    INDEX 01 24:31:61
  TRACK 10 AUDIO
    TITLE "February Stars"
    PERFORMER "Foo Fighters"
    INDEX 00 27:07:72
    INDEX 01 27:08:66
  TRACK 11 AUDIO
    TITLE "Everlong"
    PERFORMER "Foo Fighters"
    INDEX 01 31:58:12
  TRACK 12 AUDIO
    TITLE "Walking After You"
    PERFORMER "Foo Fighters"
    INDEX 01 36:08:24
  TRACK 13 AUDIO
    TITLE "New Way Home"
    PERFORMER "Foo Fighters"
    INDEX 00 41:12:27
    INDEX 01 41:12:37
  TRACK 14 AUDIO
    TITLE "Requiem"
    PERFORMER "Foo Fighters"
    INDEX 00 46:52:60
    INDEX 01 46:56:47
  TRACK 15 AUDIO
    TITLE "Drive Me Wild"
    PERFORMER "Foo Fighters"
    INDEX 01 50:30:06
  TRACK 16 AUDIO
    TITLE "Down In The Park"
    PERFORMER "Foo Fighters"
    INDEX 01 53:44:05
  TRACK 17 AUDIO
    TITLE "Baker Street"
    PERFORMER "Foo Fighters"
    INDEX 01 57:52:68
  TRACK 18 AUDIO
    TITLE "Dear Lover"
    PERFORMER "Foo Fighters"
    INDEX 01 63:30:21
  TRACK 19 AUDIO
    TITLE "The Colour And The Shape"
    PERFORMER "Foo Fighters"
    INDEX 01 68:02:35

See this here?

TRACK 02 AUDIO
    TITLE "Monkey Wrench"
    PERFORMER "Foo Fighters"
    INDEX 00 01:24:13
    INDEX 01 01:24:17

I wonder what this has to say.

So I did another test, but this time I removed the original cue file and had CUETools to generate a dummy cue file upon conversion.
Everything fine again. Accurately ripped with absolutely the same results.

This time I had this cue file:

Code: [Select]
REM ACCURATERIPID 002d23b1-0288f713-0410be13
REM COMMENT "CUETools generated dummy CUE sheet"
PERFORMER "Foo Fighters"
TITLE "The Colour And The Shape"
REM DATE 2007
REM GENRE "Grunge"
FILE "The Colour And The Shape.wv" WAVE
  TRACK 01 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Doll"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Monkey Wrench"
    INDEX 01 01:24:17
  TRACK 03 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Hey, Johnny Park!"
    INDEX 01 05:15:49
  TRACK 04 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "My Poor Brain"
    INDEX 01 09:24:06
  TRACK 05 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Wind Up"
    INDEX 01 12:57:38
  TRACK 06 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Up In Arms"
    INDEX 01 15:29:31
  TRACK 07 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "My Hero"
    INDEX 01 17:45:16
  TRACK 08 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "See You"
    INDEX 01 22:05:01
  TRACK 09 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Enough Space"
    INDEX 01 24:31:61
  TRACK 10 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "February Stars"
    INDEX 01 27:08:66
  TRACK 11 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Everlong"
    INDEX 01 31:58:12
  TRACK 12 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Walking After You"
    INDEX 01 36:08:24
  TRACK 13 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "New Way Home"
    INDEX 01 41:12:37
  TRACK 14 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Requiem"
    INDEX 01 46:56:47
  TRACK 15 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Drive Me Wild"
    INDEX 01 50:30:06
  TRACK 16 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Down In The Park"
    INDEX 01 53:44:05
  TRACK 17 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Baker Street"
    INDEX 01 57:52:68
  TRACK 18 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Dear Lover"
    INDEX 01 63:30:21
  TRACK 19 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "The Colour And The Shape"
    INDEX 01 68:02:35

  TRACK 02 AUDIO
    PERFORMER "Foo Fighters"
    TITLE "Monkey Wrench"
    INDEX 01 01:24:17

INDEX 00 01:24:13 is not there anymore. But still everything is recognized as accurate.

So I wonder what this is. Sorry for my noob questions. :/

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #732 –
Quote from: SpaceAgeHero on
INDEX 00 01:24:13 is not there anymore.
This information was lost when you removed the original CUE sheet.

Quote from: SpaceAgeHero on
But still everything is recognized as accurate.
AR doesn't use 00 indices.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #734 –
http://wiki.hydrogenaudio.org/index.php?ti...AC_Gap_Settings

Please consult the wiki or search the forum instead of asking questions that are not relevant to this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #735 –
My guess is that the gap was silence so appended or not, its null samples didn't affect the checksum.
Now as Greynol pointed out, I don't recall exactly when null samples are used or left out, but there is a rationnal explanation. I don't think the dummy cue sheet would have been accurate with gaps full of applauds or data, so your exemple is a special case that you cannot generalize.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #736 –


He's simply had CUETools generate a generic cue sheet for tracks with gaps appended to the previous track and then had CUETools convert these tracks + cue into a single-file image + cue.  There is really no need to muddy the waters with unnecessary discussion of null samples, checksums and whether the gaps contain non-null data.

It appears that this discussion has become quite bloated with unnecessary posts that aren't exactly on-topic.  I'd like to see a bit more sanity here.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #737 –
Hello,

apparently AccurateRip tags are not written into WavPack files on verification only.
Write tags on verification is ticked and after conversion everything is fine as well.
Am I doing something wrong?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #738 –
Quote from: Gregory S. Chudov on
There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc.
Eagerly awaiting new build. Tried building it from sf but only managed the C# code.

Quote from: Gregory S. Chudov on
Thanks for ideas and suggestions, i will at least consider them.
- Process unknown tags (or at least Composer and Comment) from CUE;
- Advanced Settings / Tagging / Copy unknown tags does not work for ALAC (could you at least add Composer and Comment);
- Write AccurateRip tags to ALAC;

cheers

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #739 –
Quote from: Gregory S. Chudov on
CUETools is interesting, but there's not much left to be done here. I'm always more excited by doing something new, besides i'm a bit busy at work currently.

There will be at least one more release in the nearest future, incorporating Flacuda/Flake/ALACEnc. Thanks for ideas and suggestions, i will at least consider them.

I use Cuetools 2.0.4a without problems and like the lay-out very much.
The only minor annoyance is that cuetools asks "One or more output file already exists, do you want to overwrite" when the only output file is the accurip log file.
I can see that for audio files it's a good precaution to prevent data-loss, but for the log file it's a bit overdone.
It's also a bit annoying 

Also a question:
Don't know much about the scripting possibilities yet, but if I learn more about it, would it be possible to write a script that checks a directory using 4 (or more) different pregaps?
I still have many old rips I would like to check but they are without a cue-sheet. So I would like to check those with a pregap of 0, 32,33 & 37.
(I know there are other pregaps out there (seen 1, 42)  but those are the most common ones.) 
This would make it much easier to batch check the directories. It would take some time, but at least I don't need to be at the computer to change the pregaps.


 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #740 –
Quote from: Tigerman on
The only minor annoyance is that cuetools asks "One or more output file already exists, do you want to overwrite" when the only output file is the accurip log file.
You can use a template such as this: %filename%['('%unique%')'].accurip
This way accuraterip log will be always written to a new file. Of course, this way you'll have too many logs if you recheck your files often.

Quote from: Tigerman on
Don't know much about the scripting possibilities yet, but if I learn more about it, would it be possible to write a script that checks a directory using 4 (or more) different pregaps?
Try something like this:
Code: [Select]
if (processor.ArVerify.AccResult == HttpStatusCode.OK)
    return processor.Go();
if (processor.PreGapLength != 0)
    return processor.WriteReport();;
foreach (uint gap in new uint[3] {32, 33, 37}) 
{
  processor.PreGapLength = gap;
  processor.ArVerify.ContactAccurateRip(AccurateRipVerify.CalculateAccurateRipId(processor.TOC));
  if (processor.ArVerify.AccResult == HttpStatusCode.OK)
    return processor.Go();
}
return processor.WriteReport();
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #741 –
sorry if this is the wrong place for this, but i have a quick question.

I use this tool to create .accurip files, to ensure that my large number of albums stored are accurately ripped.

Is there a way that i can drop in all my audio files (all contained in their own folders) but have the verification only proceed on folders that do not already contain the .accurip file.  I was hoping there was a way i could do this, so as to save time.  If this were the case, i could drop in all my folders, and the tool would only analyze and log the files it had not already done.

Is there a way to do this?

Thank you, and thanks for such a great tool!

Chris

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #742 –
I suppose it can be done using scripting. I will have to get back to you on this one.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #743 –
Awesome tool, I finally can convert all my Wavpacks with embedded CUEs to multifile FLACs with one click and create proper CUEs for them.

Greatly appreciated
It's only audiophile if it's inconvenient.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #744 –
I used the verification option and get the log below. Are tracks 21 and 23 OK ? What would be the reason for not being accurate on both offsets ? thanks

Code: [Select]
[Verification date: 05.12.2009 16:39:55]
[Disc ID: 004689d1-0473d2aa-67128417]
Pregap length 00:00:33.
Track    [ CRC    ] Status
 01    [031123f2] (02/04) Accurately ripped
 02    [c16fc029] (02/04) Accurately ripped
 03    [62e77d64] (02/04) Accurately ripped
 04    [820fd563] (02/04) Accurately ripped
 05    [438de18f] (02/04) Accurately ripped
 06    [b7cf0423] (02/04) Accurately ripped
 07    [e1105962] (02/04) Accurately ripped
 08    [2886560a] (02/04) Accurately ripped
 09    [eb8694cc] (02/04) Accurately ripped
 10    [4367803b] (02/04) Accurately ripped
 11    [f3f1e101] (02/04) Accurately ripped
 12    [a07d02c3] (02/04) Accurately ripped
 13    [233ece73] (02/04) Accurately ripped
 14    [6a7910d4] (02/04) Accurately ripped
 15    [4b38205a] (02/04) Accurately ripped
 16    [84b177d0] (02/04) Accurately ripped
 17    [35d3db80] (02/04) Accurately ripped
 18    [1407830f] (02/04) Accurately ripped
 19    [82e33f1e] (02/04) Accurately ripped
 20    [45d2830d] (02/04) Accurately ripped
 21    [44637312] (02/04) Accurately ripped
 22    [2301a1ba] (02/04) Accurately ripped
 23    [e75761c2] (02/02) Partial match
Offsetted by -1918:
 01    [44656175] (02/04) Accurately ripped
 02    [b2009517] (02/04) Accurately ripped
 03    [7b627e70] (02/04) Accurately ripped
 04    [d20c9978] (02/04) Accurately ripped
 05    [70812c6a] (02/04) Accurately ripped
 06    [e82cef0c] (02/04) Accurately ripped
 07    [ee044fdf] (02/04) Accurately ripped
 08    [2d3dbf89] (02/04) Accurately ripped
 09    [61c9c201] (02/04) Accurately ripped
 10    [1c569e1a] (02/04) Accurately ripped
 11    [d8080a86] (02/04) Accurately ripped
 12    [a162ca55] (02/04) Accurately ripped
 13    [36c82e0a] (02/04) Accurately ripped
 14    [b2d39da2] (02/04) Accurately ripped
 15    [ca77142e] (02/04) Accurately ripped
 16    [cc1f89c3] (02/04) Accurately ripped
 17    [9bdfbf02] (02/04) Accurately ripped
 18    [237c042b] (02/04) Accurately ripped
 19    [dee0e923] (02/04) Accurately ripped
 20    [ec1ba7b7] (02/04) Accurately ripped
 21    [b42a18ff] (02/04) Partial match
 22    [15fc9344] (02/04) Accurately ripped
 23    [ef410166] (02/02) Accurately ripped

Track    [ CRC32  ]    [W/O NULL]    [  LOG   ]
 --    [430A1C51]    [0315216C]    
 01    [A5DC11F1]    [7F01FA1E]      CRC32   
 02    [2C125DDE]    [50B52857]      CRC32   
 03    [02281225]    [C16B41B7]      CRC32   
 04    [C67D10DA]    [EE990696]      CRC32   
 05    [52BA2C35]    [E980E500]      CRC32   
 06    [3FF4C4B3]    [BB87C9DD]      CRC32   
 07    [6A68072A]    [65976004]      CRC32   
 08    [80370240]    [48958105]      CRC32   
 09    [0D60425D]    [4182DDCE]      CRC32   
 10    [5C311AEA]    [B902ED0C]      CRC32   
 11    [9747D9B3]    [410141A3]      CRC32   
 12    [A9275C40]    [B6A5B6D7]      CRC32   
 13    [F5A6A9EA]    [60DEE102]      CRC32   
 14    [679C0968]    [42455F1C]      CRC32   
 15    [A155C855]    [F5CFCB8B]      CRC32   
 16    [EEF39CA1]    [F3549D72]      CRC32   
 17    [60193F01]    [263C8151]      CRC32   
 18    [96938BCA]    [6DD4B9A2]      CRC32   
 19    [AA86D8B8]    [395F2B6E]      CRC32   
 20    [2F2D145B]    [A6836D84]      CRC32   
 21    [99036794]    [DEE2FD23]      CRC32   
 22    [1F32D768]    [AE2F1FFA]      CRC32   
 23    [B2D7DB13]    [AF382247]      CRC32

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #745 –
prefab:
3rd pressing not yet in database (... or scratches ... last track is always harder to rip for various reasons too)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #747 –
prefab:
For me, the fact that it matches accurately on another pressing is an hint that it is not a scratch, but a problem with the first/last samples of the non-accurate tracks, because if it was a scratch in the middle of the song it would not match at all on the other pressing IMHO.

... and a problem with first/last samples of some tracks + an overall low confidency level (4) is likely due to a 3rd pressing, specialy if you're sure of your ripping settings & CD physical quality.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #748 –
Great tool! With the tool I can de/encode bunch of HDCD single file image with embedded cuesheet into 24bit single track FLAC and get them nicely organised into folders automatically in several clicks.

Just wonder will it be possible to write tags in WAV files?
OR support encoding to AIFF with tags?
Thanks

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #749 –
I found a little bug in the EAC log analyzer:

For example when the log file actually contains two EAC logs (EAC appends logs to the .log file at each rip) and the rips were range copies of the whole CD (i.e. rip to one single file), then CUE Tools will treat both image CRCs as the first two tracks. This results in the CRCs being compared to the real CRCs of the first two tracks that are calculated by CUE Tools and added to the CUE Tools log.

It would be nice if CUE Tools could detect such EAC logs and either omit comparing the CRCs rejecting the logs, or use the last log in the file as the default (because we can assume it is the proper one corresponding to the audio file). Either way, the user should be noticed if there is more than one extraction log in the log file.