Skip to main content
Topic: ARCue C++ compiles and source (Read 39036 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ARCue C++ compiles and source

Reply #26
odyssey, I am not sure if your question is answered or not, but when you get something like
Code: [Select]
Tr1      ** Rip offset:   z **   (confidence y)     
Tr1          Accurately Ripped    (confidence x)


it means that your rip is accurate with X confidence, and there is another set for this CD in the database with an offset difference of Z and a confidence of y.
so for you it means all is fine, ripping finished.

on the other hand, if you have a bad rip and not the log file anymore, just the cue, you can get replies like this one

Code: [Select]
1     ** Rip offset: 2646 **   (confidence 30)   
1     ** Rip offset: 1454 **   (confidence 23)
1     ** Rip offset:  950 **   (confidence 43)  
1     ** Rip offset:  681 **   (confidence 48)


so its up to you to pick a pressing set for offset shifting. what you need to do here is looking for the highest confidence with the IDENTICAL offset value for ALL tracks.
(the codebox above shows the output for only one track)
All tracks accurately ripped

End of status report

ARCue C++ compiles and source

Reply #27
In the cuesheet I don't see that it has any pregap.
I see lot's of different pregaps lengths in that cue sheet. 

Well, let me do a recapitulation here:

Quote
I made a rip of a CD, the logfile says "Accurately ripped (confidence 4)". I rip to seperate tracks.
Can you show us the log? Did you create a non-compliant cue sheet, too?

Quote
Then I want to verify that my rip is accurate, so I use foobar2000 to convert to album images with cuesheet and verify it with ARcue plus.

Please use the original CUETools or the new CUETools instead of fb2k, but make sure you leave the "AccurateRip" setting at "Don't verify" for the new version. Load the non-compliant cue sheet to create a "Single File" (CUETools 1.9.1) or "Single File + CUE" (CUETools 1.9.2) respectively.

Then copy the non-compliant cue sheet to a new file and from that remove all lines that begin with "INDEX 00".

Now, use arcueplus on both CUE sheets to see if the result is different. It should be the same for both cue sheets. Compare the arcueplus output of those two single file rips created by CUETools, with the arcueplus output of the single file created with foobar2000.

@Gregory: maybe it's generally a good idea  to add a command line switch "--verbose" to ARCue that will give the user some more information. For example the AccurateRip ID, and the track CRCs + confidence of the other entries if there are any, and maybe some other stuff that might help identify problems.

ARCue C++ compiles and source

Reply #28
Problem found: The CD has a data track. If i'm not terribly mistaken, this track is included when AR calculates the CD checksum - Sucky!!!

Fandango: First of all, I have no idea who the hell invented "Leave out gaps" rip mode, but I wouldn't touch such a thing EVER! Secondly, the gap I were reffering to is the pregap before track01 - This is likely to cause problems, because it's not prepended when you rip seperate tracks in EAC (and it shouldn't!). Third - There's NO pregap before track 01, which is actually somewhat odd - I believe most CD's have a small pregap.
Can't wait for a HD-AAC encoder :P

ARCue C++ compiles and source

Reply #29
Maybe there is a non-audio (data) track on this CD? If there is, EAC knows it and computes DiscID with this in mind. But then when you use arcue, it doesn't know of the extra track and computes a different DiscID, so you compare your rip with the other pressing, which doesn't have a data track.
CUETools 2.1.6

ARCue C++ compiles and source

Reply #30
I wish this could be solved, but I can't imagine how...
Can't wait for a HD-AAC encoder :P

ARCue C++ compiles and source

Reply #31
I wish this could be solved, but I can't imagine how...

Maybe we could calculate datatrack's length from TOC stored in log by EAC and feed it to ARCue as a command line switch to generate dummy track?

ARCue C++ compiles and source

Reply #32

I wish this could be solved, but I can't imagine how...

Maybe we could calculate datatrack's length from TOC stored in log by EAC and feed it to ARCue as a command line switch to generate dummy track?

If I had the log in each album dir, I could simply write a script to get these AR values - no need to check files that are already logged?

And I think I have most log files, but they are all just smashed into a messy folder. Would be quite trivial to find the correct log for each album.
Can't wait for a HD-AAC encoder :P

ARCue C++ compiles and source

Reply #33
CUETools can now work with rips from enhanced CDs (with data track). Moitah made it so it can take the length of the data track from a comment in cue sheet, and i added a code to calculate the length from EAC log file. Would be great if somebody ported it to arcue, i don't have time to do everything twice
CUETools 2.1.6

ARCue C++ compiles and source

Reply #34
I downloaded the most recent ARCue and it doesn't work 

Runtime package is installed.

I just see "Not found in AR database" then comes Send error report screen.

OS: WinXP Pro (german)

ARCue C++ compiles and source

Reply #35
I have a CD image with a cue, so I check it against AR with the arcue.exe from the arcue.rar archive and the arcue.exe from the arcueplus.rar archive.

The first says all tracks are accurately ripped:


Code: [Select]
...
15     Accurately Ripped    (confidence 1)     [d4182119]
16     Accurately Ripped    (confidence 1)     [c6bfff13]


The second says all but one are accurate:

Code: [Select]
...
15     Accurately Ripped    (confidence 1)     [d4182119]
16     ** Rip not accurate **   (confidence 1)     [c6bfff13] [80bc57f4]



Which one should I trust?

Thank you.

P.S. EAC says all are accurate.

ARCue C++ compiles and source

Reply #36
The first one. ARCue++ is buggy.

This project is dead, I guess. Use CUE Tools v2 instead.


 

 
SimplePortal 1.0.0 RC1 © 2008-2019