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: Figuring out an DISC's offset ? (Read 1464 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Figuring out an DISC's offset ?

Weird question, I know.

I have a bunch of discs & images where, for a multitude of reasons, when I "Verify" them through CueTools, they are "Accurately ripped", (with confidence in the hundreds/thousands) with CTDB, but are "No match" with AccurateRip.

Based on what I've read online, I am assuming that the issue lies with wrong offset. AFAIK CTDB can match a rip regardless of the offset, whereas AccurateRip requires an exact offset match.

Is there a method to figure out the correct offset for those discs and images?
 

Re: Figuring out an DISC's offset ?

Reply #1 –
Could you post one or two example logs for reference?

It should not be necessary to apply offset to a rip but there are scripts in CUETools to do so.
korth

Re: Figuring out an DISC's offset ?

Reply #2 –
Depends on the program, PerfectTUNES can search across pressings (which is effectively different offsets), however the data needs to be there for it to do so, as the offset data could be on a different track.

Re: Figuring out an DISC's offset ?

Reply #3 –
Quote from: korth on
Could you post one or two example logs for reference?

It should not be necessary to apply offset to a rip but there are scripts in CUETools to do so.

Sure, here's two examples.

- One is a known disc which was dumped as close to perfectly as possible but still won't match with AccurateRip.
I suspect it has something to do with it being a first pressing "Enhanced" CD from 1999 (presumably early CD-Plus with some kind of mastering error)

- The other, is one of those very, VERY imperfect dumps, essentially made up from multiple sources (my original 1985 disc is damaged).

Quote from: spoon on
Depends on the program, PerfectTUNES can search across pressings (which is effectively different offsets), however the data needs to be there for it to do so, as the offset data could be on a different track.
Thanks, will have to check this out

Re: Figuring out an DISC's offset ?

Reply #4 –
* Pretty Maids: Try to make a tag ACCURATERIPID and give it value:
001522c7-00b94310-a60e110c
and run CUETools again. What do you get?

* Walls of Jericho: I find mine in your .accurip file, and it matches in 01-13 but not in 14. If you are willing to share with me track 14, I'll check for differences.

As for cross-press verification: PerfectTunes does that both for AccurateRip v1 and AccurateRip v2.
CUETools does it only for ARv1, but you can "force" it by setting the offset manually to e.g. "271" (which is on your list for Walls of Jericho), and then run again.

But I'd be surprised if it works. My "Walls of Jericho" was ripped in the age of ARv1, so I find it in your .accurip file - and matching in 01-13 but not in 14.




Re: Figuring out an DISC's offset ?

Reply #5 –
Quote from: Porcus on
* Pretty Maids: Try to make a tag ACCURATERIPID and give it value:
001522c7-00b94310-a60e110c
and run CUETools again. What do you get?
An alternative to this is setting 'Detailed log' to 'True' and run CUETools Verify again. This will provide info on any Track 1 'Pregap' or length of a possible 'Data track' (e.g. 14:20:55) to try in the 'Extra' section on next Verify.
korth

Re: Figuring out an DISC's offset ?

Reply #6 –
Quote from: Porcus on
* Pretty Maids: Try to make a tag ACCURATERIPID and give it value:
001522c7-00b94310-a60e110c
and run CUETools again. What do you get?

* Walls of Jericho: I find mine in your .accurip file, and it matches in 01-13 but not in 14. If you are willing to share with me track 14, I'll check for differences.
PM sent.

Quote from: korth on
An alternative to this is setting 'Detailed log' to 'True' and run CUETools Verify again. This will provide info on any Track 1 'Pregap' or length of a possible 'Data track' (e.g. 14:20:55) to try in the 'Extra' section on next Verify.

Here's the thing, with this image, if I try to run verify I get no matches, however if I remove the 12th track (the data track) and run verify I get a match.

Attached you can find both logs.

Thanks for the help!

Re: Figuring out an DISC's offset ?

Reply #7 –
With data track
AccurateRip ID Should be
00159122-00be6e28-ad0f8a0c
you get
0015649a-00bc57c8-b70ef20c
That's about 152 seconds short
Wonder if that's a CUETools/CTDB issue

You could try the method Porcus suggested but with the tag ACCURATERIPID
and value 00159122-00be6e28-ad0f8a0c
korth

Re: Figuring out an DISC's offset ?

Reply #8 –
Quote from: korth on
You could try the method Porcus suggested but with the tag ACCURATERIPID
and value 00159122-00be6e28-ad0f8a0c
How can I add said tag to the image?

It is currently bin/cue (since it has audio + data tracks)

Re: Figuring out an DISC's offset ?

Reply #9 –
How do you feed the bin/cue into CUETools?

For wav/cue I'd tag
REM DISCID AD0F8A0C
REM ACCURATERIPID 00159122-00be6e28-ad0f8a0c
in the cue file.
korth

Re: Figuring out an DISC's offset ?

Reply #10 –
Walls of Jericho, the 14th track, has zeroes for the last 4200-ish samples. The difference to mine - after correcting for offset - is ninety dB down. That is, only in the least-significant bit.

Looks like your drive and/or ripping application cannot handle lead-out?

Re: Figuring out an DISC's offset ?

Reply #11 –
Quote from: korth on
How do you feed the bin/cue into CUETools?
A very kind person by the name of Adam Gashlin (hcs64) created a few modified dll/pdb files which when added to CueTools 2.2.6, they enable it to understand multi-bin/cue images.

The file is still up in his webpage but I would rather not re-post it without permission.

I've used them to verify hundreds of images and then to re-encode them in bulk.

Attached you will find the new log (and cue) files.
Still weird but seem to be getting closer.

Quote from: Porcus on
Walls of Jericho, the 14th track, has zeroes for the last 4200-ish samples. The difference to mine - after correcting for offset - is ninety dB down. That is, only in the least-significant bit.

Looks like your drive and/or ripping application cannot handle lead-out?

Yes, kinda. It was copied from an imperfect CD. Just trying to "fix" it somehow...

Re: Figuring out an DISC's offset ?

Reply #12 –
Quote from: Feilakas on
Attached you will find the new log (and cue) files.
Still weird but seem to be getting closer.
Just to be clear, the cue file ACCURATERIPID tag replaces adding 14:20:55 to the Data Track box in the Extra section. You don't do both.
korth

Re: Figuring out an DISC's offset ?

Reply #13 –
I did not touch the "Extra" section at all, all three values (pregap, data track and offset) are at 0.

Re: Figuring out an DISC's offset ?

Reply #14 –
Just checking.
Next question: CUE file.
Is there a reason SESSION 01 has to be BINARY? (perhaps this method preserves the exact start position of the data track, IDK)
SESSION 02 has to be BINARY, but why don't you store SESSION 01 as FLAC?
korth

Re: Figuring out an DISC's offset ?

Reply #15 –
"Redumper" is indeed an archival-grade tool, created for optical media preservation, and my aim from the get-go was indeed to preserve my collection as best as I could.
By design it creates as close to a bit-perfect copy as possible (there are some rare outlier cases but these are very few and far between).

However, at the same time I just plain didn't feel like adding an extra step.

Redumper dumps images in bin/cue form.

Switching to flac would add an extra conversion step. The total size is about 500GB which by today's standards isn't terribly large and for everyday use I batch-converted them to MP3 (simple, small, universal and "good-enough" for most everyday applications).

Plus, I noticed that cuetools does all kinds of weird things with the images and the cues it produces have significant differences from the original ones, meaning that I wouldn't be able to "go-back" if I wanted to for whatever reason.

Re: Figuring out an DISC's offset ?

Reply #17 –
Quote from: Porcus on
Interesting tool, it archives subchannel too?
Indeed it does: https://github.com/superg/redumper

Quote
Subchannel data is stored uncorrected RAW (multiplexed). Both TOC based and Subchannel Q based splits are supported, subchannel Q is corrected in memory and never stored on disk.

If you're feeling super paranoid you can even retain the "raw" dump file "scram" which contains 99% of the disc's information (the rest being stored in MUCH smaller files which is always a good idea to preserve).
Normally, the scram file is used as the base for "splitting" the image files (bins & cue).

However, it is a command-line tool so I use it together with "MPF", a front-end tool, designed for archiving optical-based games but works for audio-cds just fine.

Re: Figuring out an DISC's offset ?

Reply #18 –
DataCDs have much better error checking than audio CDs, there is a C2 detection hole so to speak, it was decided to reduce the error detection to fit 74 minutes on a CD.

Re: Figuring out an DISC's offset ?

Reply #19 –
Quote from: spoon on
DataCDs have much better error checking than audio CDs, there is a C2 detection hole so to speak, it was decided to reduce the error detection to fit 74 minutes on a CD.

Did not know that.
Learn something new everyday :)