Hey everybody,

I have an offset-related problem and hope someone here can help out. I'll be short and precise:

1. Received an EAC-made CD-Audio IMAGE along with its LOG and CUE

2. LOG indicates secure ripping, but NO READ OFFSET CORRECTION

3. CUE seems of the noncompliant form

4. I know both the READER's READ OFFSET as well as my writers WRITE OFFSET

Is there a way to create a CD using my burner in EAC, that I can rip using EAC and get results in ACCURATERIP that are actually accurate? How would I compensate for that missing offset during readout? Would I add the missing read offset to my write offset when burning this CD?

Any help is gladly appreciated.

Thank you.

flacflac

Rather use CUE Tools (offset correction) and then ARCue.exe (AR check) on that Audio CD image. Much faster and you don't need a CD-RW.

Hi Fandango,

Thanks for this tip - it definitely saves my resources, thank you. Unfortuntaely, I still don't know what settings I should use. I created a new WAV image using either NO offset, or the supposed read offset or the supposed write offset, none of these "tricks" made the files accurate. What's the right way to proceed with files that come from a non-offset-corrected rip?

Thank you.

flacflac

You need to know the right offset correction, in other words you need to know the offset correction for the drive that was used to rip the Audio CD.

Take a look in the EAC log and copy the name of the drive to the clipboard. Then go to the AccurateRip website's drive database and search for that drive. Ctrl-F, Ctrl-V, Return should work most of the time... if not, shorten the drive model name a bit. Often removing the single letter at the end of the model name will give a match.

Now you got the offset correction, just use that in the advanced settings of CUE Tools (no need to negate it!), accept the warning and convert to "Single File"... then do "arcue.exe <CDImage>.cue"... and hopefully the rip will be in the AR database.

After CUETools use TripleFlac! to test for Accuraterip match.

//EDIT: At the moment TripleFlac can only test flac files for accuraterip matches.
//EDIT: TripleFlac can test albums offset from the AR one. It can tell you that your album is accurate, but it is X samples away from the one in the database.

I actually do this, adding the missing read offset to my write offset and it does work . Just give it a try.

Thanks for the replies, folks. I appreciate your help.

Unfortunately, that specific rip seems to have been bad, as none of the tracks are recognized in AR, even though I have the same CD and tracks ARE in fact getting AR results - unfortunately, one track is damaged, so I guess that's a rebuy... .

But it's great to have ARCUE as an executable. Are there any additional command line options that can go with it, or is it "as is" without documentation?

ONE MORE THING: If I test a rip of which I do not know the drive (hence not know the offset), and all results are ACCURATE using ARCUE, except for the final track - is there an explanation for this besides "the ripper did a lousy job"? Can the offset be wrong even though all the previous tracks are accurate?

No. However, be careful with small (<4) confidences. Sometimes the same album is multiple times in ARdb, some of them is some samples away from the other: The ones with small confidences are unreliables.

Can somebody tell me how arcue works? I open the arcue.exe file and it doesn't do anything.

You need a .WAV image and a corresponding cue-sheet. Then you open that cue in arcue, meaning you start the command prompt (RUN --> CMD.EXE). Easiest way is to copy ARCUE.exe into the folder where CUE and WAV are located. Go to that folder in your command window, then run ARCUE saying:

arcue.exe cuename.cue


That's it.

I am still wondering whether there are any additional command line arguments.

There aren't any. It only requires one argument, the cue file, all following arguments will be ignored. If the first argument is not a cue file it aborts with an error.

And when the last track is wrong, then the guy who ripped the CD did a lousy job, he enabled "read into leadin/leadout" when in fact the drive he used doesn't support it.

When the CD is "not in the database" or you don't know what drive was used, hence don't know the correct offset, you could give this TripleFlac! a try... I haven't actually tried it myself, and never heard about it, nor do I find a thread about it here at HA.org. But it seems to be a EAC plugin, because on my system it cannot find an entry point in a library (probably EAC.exe) and it comes with EAC language files. But a small tutorial would be fine...

Works great, just a quick question on some of my files when I go to do a local CRC check, it gives me this message Some or all tracks have a non-zero offset. What's that and why do only some files say it?

Thank you man. It does work perfectly .

This software is in alpha state right now. It also reports "some" when all of the tracks have non-zero offset. Probably the album was ripped with wrong offset correction, or a write offset was applied to the tracks by CueTools.

However if only some of them became yellow, thats really weird if all of them are from the same source. Check the offset column and if you see nonzero numbers, try to correct them with CUETools.

This is the standard procedure. For example look at this log file:



We will make sure it's still accurate! Lets say it was splitted (but not offset corrected) to multiple files using CUETools or shntool before.
1. You should check the drive's read offset in the AccurateRip database:

In this case it is +667. Note it down!
(2.) However you know that the entire album is 667 samples away, you can check them for accuraterip confidence with TripleFlac! if you want. Probably it will report an offset identical to the drive's read offset.

3. CUE Tools will help to shift the contents of the audio files. Type the drive's read offset correction as write offset at the advanced tab. YES, in this case you should give positive number if the read offset correction is positive!


Convert it!

You need to have the relevant cue sheet with correct audio file names in it to be able to do this step. If you have multiple files but only a single image cue sheet (perhaps because you've splitted and deleted the image file) then you should join the files together first by using shntool's join command. You can use CUE Tools' 'Filename Corrector' to simply solve the second issue.
4. Use TripleFlac! to check if your files are accurate:


Thats all. Of course if your files have different offsets (weird) you may need to repeat this procedure with another offset correction. Make sure you always try to match files to a high (>=4) or HIHGHEST confidence offset.

Cheers,
RS

Thanks for the help. it fixed it. The tracks with problems were because I had ripped without a read offset correction, then burned (no write offset needed) and then ripped again. So they were off effectively double the offset correction.So they great thing about this is, even if you have rips done before AR you can still have them accurately ripped. Why are the multiple offsets listed?

And the other great thing is I can use the offset correction with CueTools and then send the CUE file to Burrn and have it burn accurately

It is possible to report rips to the ardb which arent properly offset corrected. AR will save them in the database. Thats why i said to trust only the high values. (Mass report these improper rips have low probability.) But keep in mind that it is also possible that a different pressing is some samples away from another.Yes.

These are just different pressings; really nothing to be concerned about, and certainly nothing to malign.

Hmm, only if your write offset is same to the read offset correction.

Ok, I was strict. You can see in the example that there are 5 "different" pressings with confidence levels of 3,4,12,36,200. It is advised to match the files to the 200.

I didnt malign AR. It is possible to report a CD-R rip (like Mitch A's). There are famous drives, and there are people who rip and/or burn without offset correction. This phenomena could result CD-R-s with same offset from the original albums. If some of them were re-ripped with read offset correction they could appear in the AR db. Thats not an attack against AR, i just said i would not trust the confidence of 3 above if there is also a 200.

//EDIT: Oh, and ive also said that i mean 4=< as 'high' confidence. I think that is reasonable, if there are more values to chose from.

RamonSalazar,

When I trying to select any folder wich contains .flac I get an error



XP Pro SP3 + .NET 2.0 SP1

Sorry, I meant the same offset as my drive, not double.

Now with shifting the sample forwards to match my drive, do I actually lose any audio data? Becasue if you do then how is it considered accurate?
And say if you rip is confidence is 10, you can actually shift the samples to match a higher offset and get a higher confidence. But obviously there's not really any point doing that when your rip is already accurate

I will forward this to the programmer. Only if the replaced samples were not originally null samples. CUE tools inserts null samples by offset correction. There is no problem if the original audio data in the corresponding area were originally nulls. You can test the amount of null samples at the leading part of track1 and the trailing part of the last track. Most of the audio discs contains at least 5000+ silence at leading and trailing area. You can check it, but you must know there isnt a big deal to loose less than 1600 samples from the beginning or from the end of the album.

Watch THIS.

I won't worry about it, my drive only has an offset of +12 so I'm sure I'm not losing much, thanks

Download (using libFlac1.1.4) - only use this if you have problems with the new libraries!!

Thanks, works fine now ;-)

this little app is a god-send... i have myself fixed a couple of wrong off-set rips!

Update: I am not getting something... to "fix" a rip, do I need the original log file with the read offset being shown? - and in CUE Tools do I need to enter "THAT" log off-set number to have the new WAV re-written properly?
What about plain flac files with no log or drive information... are the shown offsets in tripleflac valid at all ?

In this case below, the rip was done with a 48 read off-set.
The ARDB is only showing a -635 offset, so that means I shouldn't correct this rip... only if it had the 48 value?

That's the slightly confusing thing I found, I have alot of rips which all came back as different pressings even though there secure with matching CRC's. However in TripleFLAC it claims the offset is non zero. So should I shift the samples to the ones listed or just leave it?

Confidence level 9 is high enough to correct that rip with 635 samples. Maybe that rip is a different pressing which differs only with a sample shift from the regular one. Maybe that was ripper from a CD-R. Maybe the log file and the music files are from different source.

Thanks for your question, im doing fine However i will be away for three months in the near future.

TripleFlac checks for AR match. If you want to match your music files to AR database, then yes.

OK, I got it, different pressings may be matched to the AR database. Could one rip be shown as "corrected" and in fact not being "perfect"? If you know what I mean...

Tracks that are unfixable at all mean that they're really have a flaw right? (Meaning that if a track is fixable, it will always be perfect) ... And also, with this method, I can forget about the non-submitted CDs (which will be not fixable at least for now).

How does the program discover the offsets reading the local stored FLAC files?

Do you mean manual offset correction of the audio data as "fixing"? If so, yes. AR (as i know) uses CRC32 hash algorythm on the audio data (except the leading and tailing 2040(im not sure) samples. If you are paranoid, you can't be sure the missing part is perfect. However, if AR reports the track is in the database, you can consider it "perfect". TripleFlac (i think) does many CRC check for the audio data to determine it's offset from the AR ones. I dont know its algorithm, but it works well. If it reports the track to be x offset from the one in the AR database, you only need to shift the track manually (Cuetools) to "fix" it. If an album is not in the database, there is nothing to match or compare. It doesnt mean automatically that that album was not ripped perfectly. Best way to check it is to rip it again with another drive. If you dont have the disk and it is not in the ARdb too, you should wait until there is enough submissionsions to the AR.

In order to check for offset correction, AR computes a checksum over one frame of audio data six seconds into each track.

I mean, that I am actually "removing samples with audio" from the reportedly wrong rip, by using CueTools and shifting the samples. Would it add "silence" or "cut audio" by fixing it with CueTools just to have the rip as a match...(but not being entirely perfect)?

If you want perfection go buy the CD.

I agree.

Cuetools adds nullsamples and cuts audio data if needed. If the original audio data is silence on that area, you will get "perfect" result.

Oh Oh, I knew something wasn't perfect.... LOL
"Go buy the CD" is a weakened argument these days. The price usually hits the stratosphere, and well mastered ones you have to hunt down.

It is your argument that is the weakened one.

The CD you have chosen to steal does not offer alternatives when it comes to mastering; it is new.

Thank you for pointing that out; I deleted the FLAC files, and I trashed the burnt CD. Many thanks.

Just on this topic of burnt CD's. If you rip an original with your drive correct offset and then burn a CD, the CD tracks are then verified as AccurateRips can you use it or do you have to use the original for a perfect copy?

Mitch, not sure if I understand you correctly but: if you ripped accurately with offset correction, and then burn a CD from these files, you can only get accurate rip results from that burned disc if you use the correct WRITE offset correction. If you do so, then yes, I would think you can definitely use it to rip from again. (although that might seem like an unnecessary task altogether... ).


MiD30: Regarding these strong adjustments advised by TripleFlac, I would simply use it for testing purposes, but not alter the files entirely. If you checked whether they either ARE accurate or COULD BE MADE accurate, I would just leave it at that, and if you ever decide to burn them to a CD then apply these changes for these temporary files. Otherwise you might really cut into your audio, and, like greynol pointed out, you would really want the original CD if you need to have files that are actually perfect. That's the way I use Arcue.

flacflac

Yeah that's what I meant. Reason I was asking was just incase I lose the flac files & the CD gets scratched, I can then still use a burnt copy and be certain that it will be accurate.

Thanks for TripleFLAC, it's an amazing program!
We also had in Russia some experimental methods - the worst one is to Brute-force all the offsets from -2000 to 2000 using script & checking with ARCue! Cool, yeah?

It'll be great if you added the WAV compatibility to TripleFLAC at least, it's not very proper to convert WavPack, TTA, etc. to FLAC and then check...

Have you tried an AuCDTect checker for foobar2000?
Here: fooCDTect

Program can be determined as virus by Avast - it's not true. The pack includes sources and image with config example.

BTW, we use EAC to correct offset, just mount the image and rip it with needed correction also Secure.
And then you have the common logfile to show everyone...

Hello All.
I need some advice as I don`t know how to go on.

I have 3 CDs which are not in the AccRip DB (assumedly). Thanks to tripleflac's Leadin Bruteforce I could find them however (all in range 30-40 FrameNOs)

now my problem:
How do I correct these files with CUETool?
because they need Leadin AND Offset correction.


please help.
greetings,
Parsi


edit for future generations:
I figured this out on my own with great help from Greynol
basically you need to add a Pregap Statement BEFORE the first Index entry according to the bruteforce value in tripleflac (for me it was all between 32-37 frames)

(info from greynol)

would become


you have to do this in the original cue file then open the edited .cue in cuetools, enter neccessary Offset values and then save as single wav+cue to check with arcue... you have to do this in one step with cuetools..

good luck, thanks for the progs, though very very buggy
Parsi

Hi everybody,

Where can we download the latest TripleFlac! release ? Is there some official site or something ?

Thank you.