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: EAC: Burn non-offset corrected image WITH correction? (Read 35180 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC: Burn non-offset corrected image WITH correction?

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 

EAC: Burn non-offset corrected image WITH correction?

Reply #1 –
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.

EAC: Burn non-offset corrected image WITH correction?

Reply #2 –
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


Quote from: Fandango on
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.

EAC: Burn non-offset corrected image WITH correction?

Reply #3 –
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.

EAC: Burn non-offset corrected image WITH correction?

Reply #4 –
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.

EAC: Burn non-offset corrected image WITH correction?

Reply #5 –
Quote from: flacflac on
Would I add the missing read offset to my write offset when burning this CD?


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

EAC: Burn non-offset corrected image WITH correction?

Reply #6 –
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?



Quote from: Juan C. on
Quote from: flacflac on

Would I add the missing read offset to my write offset when burning this CD?


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

EAC: Burn non-offset corrected image WITH correction?

Reply #7 –
Quote from: flacflac on
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.

EAC: Burn non-offset corrected image WITH correction?

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

EAC: Burn non-offset corrected image WITH correction?

Reply #9 –
Quote from: Juan C. on
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.

EAC: Burn non-offset corrected image WITH correction?

Reply #10 –
Quote from: flacflac on
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...

EAC: Burn non-offset corrected image WITH correction?

Reply #11 –
Quote from: RamonSalazar on
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.


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?

EAC: Burn non-offset corrected image WITH correction?

Reply #12 –
Quote from: flacflac on
Quote from: Juan C. on

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.


Thank you man. It does work perfectly  .

EAC: Burn non-offset corrected image WITH correction?

Reply #13 –
Quote from: Mitch A on
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?
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:

Code: [Select]
EAC Auslese-Logdatei vom 7. März 2006, 13:48 für CD
David Gilmour / On An Island

Benutztes Laufwerk : HL-DT-STDVDRAM GSA-4163B   Adapter: 1  ID: 0
Lesemodus          : Sicher mit KEINEM C2, Accurate Stream, KEIN Puffer abgeschaltet
Kombinierter Lese/Schreiboffset Korrektur : 0
Überlesen in das Lead-In und Lead-Out : Nein

Benutztes Ausgabeformat : Interne WAV Routinen
                     44.100 Hz; 16 Bit; Stereo

Andere Einstellungen       : 
    Fülle fehlende Offsetsample mit Stille auf : Ja
    Lösche führende und nachfolgende stille Blöcke : Nein
    Installierte externe ASPI Schnittstelle


Bereichsstatus und Fehler
Gewählter Bereich
     Dateiname D:\Neuer Ordner\David_Gilmour_On_An_Island.wav

     Spitzenpegel 100.0 %
     Bereichsqualität 99.9 %
     CRC EB46671E
     Kopie OK

Keine Fehler aufgetreten

Ende des Statusreports


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

EAC: Burn non-offset corrected image WITH correction?

Reply #14 –
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

EAC: Burn non-offset corrected image WITH correction?

Reply #15 –
Quote from: Mitch A on
Why are the multiple offsets listed?
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.
Quote from: Mitch A on
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
Yes. 

EAC: Burn non-offset corrected image WITH correction?

Reply #16 –
Quote from: RamonSalazar on
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.

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

EAC: Burn non-offset corrected image WITH correction?

Reply #17 –
Quote from: Mitch A on
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.
Hmm, only if your write offset is same to the read offset correction.

Quote from: greynol on
These are just different pressings; really nothing to be concerned about, and certainly nothing to malign.
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.

EAC: Burn non-offset corrected image WITH correction?

Reply #18 –
RamonSalazar,

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



XP Pro SP3 + .NET 2.0 SP1
Thinking Outside The Box

EAC: Burn non-offset corrected image WITH correction?

Reply #19 –
Quote from: RamonSalazar on
Hmm, only if your write offset is same to the read offset correction.


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

EAC: Burn non-offset corrected image WITH correction?

Reply #20 –
Quote from: Kirya on
When I trying to select any folder wich contains .flac I get an error
I will forward this to the programmer.
Quote from: Mitch A on
Now with shifting the sample forwards to match my drive, do I actually lose any audio data?
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.

EAC: Burn non-offset corrected image WITH correction?

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

EAC: Burn non-offset corrected image WITH correction?

Reply #24 –
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?