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 1926102 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #700 –
Quote from: Dirki on
How can I set this format when encoding using a cue sheet:

Input:
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep.cue

Output:
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep (1987)\01. In The Name Of Money.wav
H:\Musik (original)\Alben\Gino Vannelli – Big Dreamers Never Sleep (1987)\Gino Vanelli - Big Dreamers Never Sleep (1987)\02. Time Out.wav
...

Nice greetings, Dirk


And I tried this template:
[%directoryname%\]%artist% - %album% %year%[%unique%]\%filename%.cue
Win 7, Win Vista, newest stable foobar & EAC & Cue-Tools

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #701 –
Quote from: Vomitus on
I was trying to embed cue sheet with reencoding source into flac file and found these two possible bugs:
1. When encoding with internal flac encoder it utilizes only 1 core of dual-core processor. However, standalone flac encoder uses both cores (which in fact speeds up encoding process up to 40%).
2. One of created flacs this way was kinda broken: I was unable to add ReplayGain info into it using foobar("Could not update tags (Unsupported format or corrupted file)" was the message). However, if reencoded with standalone flac encoder, this bug was disappeared.


From what I believe, there are two different FLAC encoders possible to use in CUETools... that is FLACLib and flake. One is obviously the "original" flac encoder library, the other is made by someone else... (chudov, maybe? i am not sure). i know he was making some changes with it. is it possible that the alternate one is selected? also you may check the options for these encoders under the 'encoders' tag in the options. to make sure everything is how you want it.

ultimately, it sounds like some non-standard stuff is going on. here is the method I personally use,when ripping original CD's... may be a little longer, but doesn't really bother me:
1) rip with EAC -- test & copy, create image w/ cue
2) go into FLAC frontend (the one that comes with the FLAC codec pack) and encode mine using only compression 8 and 'verify' checked. (compression/decompression speed is not a factor for me, i have a very fast machine) i do not embed the cuesheet here.
3) go into foobar, add the single FLAC file to the queue, then embed the cue file inside of foobar. i have to close the program out and re-open it, or remove/re-add the FLAC file for it to actually show the tracks split out and tagged (is there a quicker way to do this? i tried reload tags/info... didn't work)

yes, i know i could actually combine step 1 and 2, it's just half a second longer. though, i'm not sure if it keeps the original WAV file when you use the encoder option in EAC. I'll have to check that out. can't remember.

Either way, I have had nothing but success with this, never a single problem. not to say there is anything wrong with CUETools, as I haven't really used the transcoding feature but once or twice, i use it primarily for its VERIFY function... I do all of my splitting/transcoding/decoding/cuesheet&tagging, etc in foobar2000. still, CUETools is a great program and I couldn't do without it.


so i ask again, what format are your original files in (codec).... and are they single file or file-per-track?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #702 –
Quote from: Chinch on
From what I believe, there are two different FLAC encoders possible to use in CUETools... that is FLACLib and flake. One is obviously the "original" flac encoder library, the other is made by someone else... (chudov, maybe? i am not sure). i know he was making some changes with it. is it possible that the alternate one is selected? also you may check the options for these encoders under the 'encoders' tag in the options. to make sure everything is how you want it.

I use 1.9.5a version and it has no flake as I believe. And the only option there is encoding level and 'verify' checkbox. What concerning 2.xx versions - its interface just overwhelmed me(it is too alpha to use it and it requires huge reconsideration, but that another story). I can't test now on 2.x version because I already have no source, but the source was single flac file with less compression level.
Well, I post here not to solve my personal problem but make developer to be aware of possible bugs. Concerning multicore CPU load it seems it's a problem of original flac encoder, because it often uses only one core too. But the problem with "corrupted" resulting flac file? This one confuses me.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #703 –
Hello!

Can someone please give me an exact explanation of these tag fields written by CUETools?

<ACCURATERIPCOUNT> : 2
<ACCURATERIPCOUNTALLOFFSETS> : «multiple values» 273; 272; 270
<ACCURATERIPCOUNTWITHOFFSET> : «multiple values» 139; 137; 136; 138
<ACCURATERIPOFFSET> : +688
<ACCURATERIPTOTAL> : «multiple values» 273; 272; 270

What actually indicates that I have an accurate copy?

One more question:

Assuming I had only the tracks of an album without the original cue file. When I now compress it to a single WavPack file using CUETools it tells me my copy is accurate and embeds a dummy cuesheet. Is there any difference to the cuesheet file EAC would have created during ripping?

As long as CUETools tells me its accurate there is actually no need to keep external cue/log files, right?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #704 –
I would compare the tags against the output of the program.. both in normal and verbose mode... that way you can more clearly see what values mean what. Could you post the output for this in compact (non verbose) mode? We could probably clarify much easier.

As far as the cue sheet goes, yes there are differences in the dummy cue sheet vs. a normal one. for instance, (I'm not sure exactly how Mr. Chudov creates the "dummy" cue files), but I would imagine that they are simply as implied.. fully generic cue files, just enough info to comply to the CUE standards. for instance, some things it may be missing vs. an EAC cue file could be optional entries such as ISRC codes, possibly pregap or an entry for any data previous to the first track... it may all be based on 00:00 indexing.. these are all assumptions as I tried against a FLAC file with embedded cue, and it pulled the correct cue from the internal FLAC data, as it should. I tried extracting to a single WAV file, then creating a cue file, but it seems to be greyed out and won't allow me to do it. I'm assuming since they are not multiple tracks with their own song titles, etc... it does not know where to get the number of tracks, each track's length, etc... so it would be pretty difficult to determine what it actually was, without any information, especially since WAV format does not support tagging... if you ONLY had a single WAV file, I would assume that the only way it could be matched against anything was an MD5 or better yet, SHA-1 checksum of the WAV file itself.

(Although if you had the corresponding LOG file with TOC data in it, it could feasibly be parsed)

Hope you get what I'm saying... if not let us know.. maybe someone else can explain in their own terms as well, or the author can extrapolate and/or clarify the answer to your question.

edit: in re-reading your post, i see that you are compressing to WAVpak... and to be honest, I'm not entirely familiar with it, other than it is one of the many codecs available to compress audio. not sure what tagging it uses (id3, vorbis, etc). but personally, i *always* keep the original CUE and LOG files, regardless if they are embedded or not. who is to say the tag may one day be damaged or overwritten, etc.... then there goes your info. so it is my advice to definitely keep both of these files, the CUE being the more vital of the two, but the LOG file does contain some valueable information, such as what drive was used, what read offset was applied, what mode and options were used for extraction (ie, burst mode, secure...... C2 on/off, defeat cache on/off, whether it was test and copy or just copy...... etc). while embedded CUE's are a great invention/thought in my opinion, they are merely an accessory to the original files.. it all depends on your needs and plans for the end-result files, and how important this data is for you to know.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #705 –
Code: [Select]
[Disc ID: 000dd63b-006583a0-83099c09]
Offset applied: -12
Track	[ CRC    ] Status
 01	[ba95e59a] (02/273) Accurately ripped
 02	[a8de475e] (02/272) Accurately ripped
 03	[03219797] (02/270) Accurately ripped
 04	[3de7bdf7] (02/270) Accurately ripped
 05	[850d915c] (02/272) Accurately ripped
 06	[69b9e193] (02/272) Accurately ripped
 07	[f9a80d41] (02/272) Accurately ripped
 08	[5898d55b] (02/273) Accurately ripped
 09	[ef69e35b] (02/272) Accurately ripped
Offsetted by 329:
 01	[217d2cb7] (05/273) Accurately ripped
 02	[035c1d8c] (05/272) Accurately ripped
 03	[a533954d] (05/270) Accurately ripped
 04	[d1f7212f] (05/270) Accurately ripped
 05	[9a2463af] (05/272) Accurately ripped
 06	[904d925e] (05/272) Accurately ripped
 07	[17cae0f8] (05/272) Accurately ripped
 08	[34343d89] (05/273) Accurately ripped
 09	[c8271051] (05/272) Accurately ripped
Offsetted by 341:
 01	[1cd853e0] (04/273) Accurately ripped
 02	[91da70b4] (04/272) Accurately ripped
 03	[9d7d875a] (04/270) Accurately ripped
 04	[e1d83940] (04/270) Accurately ripped
 05	[6748aa4c] (04/272) Accurately ripped
 06	[a9d12131] (04/272) Accurately ripped
 07	[d0e63c0e] (04/272) Accurately ripped
 08	[6c22ff5c] (04/273) Accurately ripped
 09	[67203a95] (04/272) Accurately ripped
Offsetted by 676:
 01	[922d88d6] (96/273) Accurately ripped
 02	[b6776a6b] (97/272) Accurately ripped
 03	[1fedfbf8] (96/270) Accurately ripped
 04	[eee24ed4] (95/270) Accurately ripped
 05	[c3e2e7d8] (96/272) Accurately ripped
 06	[9765fb3c] (96/272) Accurately ripped
 07	[cddeaa76] (97/272) Accurately ripped
 08	[629629fb] (98/273) Accurately ripped
 09	[453a7cea] (97/272) Accurately ripped
Offsetted by 679:
 01	[9f975e6e] (02/273) Accurately ripped
 02	[5a2867c4] (02/272) Accurately ripped
 03	[b7721e2d] (02/270) Accurately ripped
 04	[bd11a24e] (02/270) Accurately ripped
 05	[b472399f] (02/272) Accurately ripped
 06	[bfc91568] (02/272) Accurately ripped
 07	[70fe8f61] (02/272) Accurately ripped
 08	[ec601096] (02/273) Accurately ripped
 09	[ee968783] (02/272) Accurately ripped
Offsetted by 688:
 01	[4243df36] (139/273) Accurately ripped
 02	[5dea426d] (137/272) Accurately ripped
 03	[9f134244] (136/270) Accurately ripped
 04	[6ad09f50] (137/270) Accurately ripped
 05	[b95b2ee4] (138/272) Accurately ripped
 06	[42aa5b5d] (138/272) Accurately ripped
 07	[106f485b] (137/272) Accurately ripped
 08	[8ad24295] (137/273) Accurately ripped
 09	[eac5a754] (137/272) Accurately ripped
Offsetted by 1334:
 01	[e610378c] (25/273) Accurately ripped
 02	[f3d1de68] (25/272) Accurately ripped
 03	[93f18218] (25/270) Accurately ripped
 04	[58080aa6] (25/270) Accurately ripped
 05	[c475ac1c] (25/272) Accurately ripped
 06	[1f85bfab] (25/272) Accurately ripped
 07	[496ebe59] (25/272) Accurately ripped
 08	[0cdc2a7a] (25/273) Accurately ripped
 09	[5031f924] (25/272) Accurately ripped
Offsetted by 694:
 01	[32a6a20e] (00/273) No matches
 02	[024e5e9d] (00/272) No matches
 03	[a6729aa7] (02/270) Partial match
 04	[21764818] (00/270) No matches
 05	[095b9925] (00/272) No matches
 06	[20cb77ec] (00/272) No matches
 07	[62d12e31] (00/272) No matches
 08	[9e0d8cba] (00/273) No matches
 09	[3d9dbc92] (00/272) No matches

Track	[ CRC32  ]	[W/O NULL]	
 --	[AF100B4F]	[2456AB51]	
 01	[4228669B]	[7BF7F2E1]	
 02	[238807CB]	[CD4C285F]	
 03	[8315A79F]	[BC9DBD64]	
 04	[64962211]	[4BE360F0]	
 05	[7EE2427E]	[70DD89C0]	
 06	[5B5A9439]	[D28DEA76]	
 07	[0F5658D0]	[96EB0926]	
 08	[492D73CF]	[D2173540]	
 09	[A10D8475]	[EF74D31B]
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #706 –
OK, i can explain this to you... sorry if i you already understand this.

These groups of entries means that your rip had 02 matches of this CD, after applying the closest matching offset (-12), to bring the offset to 0, which is what you want, otherwise without that applied, your CD would have zero matches.  The following entries are other rips, with differing offsets to yours, but the "audio data" still is exactly the same as that rip (after applying that offset to your rip). So ultimately, it is saying that your CD had 02 matches out of 272 or 273 total. So each group is a match, with "offset xxxx" relative to your copy.

That is, the next closest rip to yours would be the next one, "Offsetted by 329", which means the data for that submission matches your CD exactly, although we'd have to apply +329 samples(?)  for them to match. once we apply that "offset", they match perfectly.

Same with the rest.

Seeing as though this was an encode, you probably have the options set to choose the closest offset to yours, then shift your rip by that amount of samples, then re-encode, so that it has some matches, rather than none. The reason for this is you would not want to apply the 1334 offset vs. -12 offset, because that is more data lost or samples difference from yours. In your output, it appears that the pressing with the offset of 688 is the  most "popular" or "frequent" result, since it has the most matches.. but that is not necessarily meaning that it is the "right" one, as there can be multiple "right" ones.

Hope that is clear to you, I tried to make it as understandable as possible! if you have questions or would like me or the others to expand on any of that, just let us know!

[edit] to directly answer your original question, referencing this:

<ACCURATERIPCOUNT> : 2
<ACCURATERIPCOUNTALLOFFSETS> : «multiple values» 273; 272; 270
<ACCURATERIPCOUNTWITHOFFSET> : «multiple values» 139; 137; 136; 138
<ACCURATERIPOFFSET> : +688
<ACCURATERIPTOTAL> : «multiple values» 273; 272; 270

This shows your rip is 'accurate' or matching to 2 other people's rips. the next line shows the total amount of entries for this CD in the AR database including all the different offsets, the third looks like the highest count of matches for any single rip, the fourth is the "most frequent" or rip with the most submitted matches, and again, the last is probably the total number of entries, including zero offset entries and offsetted entries.

The "true" answer is that your copy did not match ANY of the entries in the AR database, it was only after offset of -12 was applied to it that it now matches 02/273 of the disc entries in the DB.

The "ultimate" match or result would be your CD matches the most popular pressing, at zero offset (meaning it did not have to be changed at all to match these, it did right off the bat). So essentially, we could assume two things -- 1 your rip is "wrong" since your drive needs an offset applied to it for ripping and wasn't, so it is inaccurate. The second possibility is that you just have a completely unique pressing that nobody else has submitted.

Do you have any offset put into the options in EAC? If not, then that is probably the problem. (or if it was downloaded, they likely didn't enter the correct offset for their drive).. aka they didn't really know how to rip CD's properly.. this is why you can never really trust downloads to be "true". they could have been ripped with a terribly wrong offset, then applied to furthest matching offset (say, 1300). In this case, you would be missing data from the original audio, and never know it... it would check out correctly if you used CUETools/AR to check it after the offset had been applied.

As some may technically correct, even such a large offset applied is very unlikely to actually destroy any real "audio", the point is... it's not an identical/truly accurate rip of the CD.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #707 –
Thank you very much for clearing that up so detailed. I do understand that now.
Now I wonder what that offset data usually is. Is that actually some kind of padding?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #708 –
Quote from: Chinch on
The "ultimate" match or result would be your CD matches the most popular pressing, at zero offset (meaning it did not have to be changed at all to match these, it did right off the bat).
Thankfully you're using quotes since this is nonsense and I fear that making these kinds of statements is misleading.

Quote from: Chinch on
(or if it was downloaded, they likely didn't enter the correct offset for their drive)
This is easily fixed by supporting those creating and delivering the music rather than stealing from them.

Quote from: Chinch on
As some may technically correct, even such a large offset applied is very unlikely to actually destroy any real "audio", the point is... it's not an identical/truly accurate rip of the CD.
You are aware that the offset reference that was adopted has been legitimately called into question(?), so by your rationale, rips approved by AR aren't identical/truly accurate rips of the CD either.

My 2 cents (which was likely posted long ago in this thread):
All you need is for your rip to be verified by a complete set of tracks with the same offset to be pretty much guaranteed that there was nothing wrong with it.  Sure you can correct your offset so that it matches a particular pressing and perhaps it might correct your drive's offset to match the reference in the event that the correction wasn't configured in the first place.  Doing so will possibly throw out even more data, though what might be thrown out is likely nothing more than a very low-level signal found at the edge of the disc.  There may also be situations where tracks aren't cut properly and they either start or end abruptly with the rest of the data being assigned to the edge of an adjacent track.  An offset (sometimes thousands of samples) might actually fix the problem but cause the disc not to match a pressing in the database any longer.  In this situation, which offset would you prefer?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #709 –
sure, the information is usually silence/null samples... which basically means... 'nothing' is usually there. nothing of value, anyway.

i believe i read somewhere that there is usually a set amount of samples that most CD makers usually have as padding at the start and beginning of a CD, though i don't think they're required to. ultimately though, if you think about what it really is... samples... these are fractions of a second. so you would have to have a HUGE offset screwup to actually be cutting off audio. i believe (i could be wrong or off a bit, feel fee to correct me) that the frequency of an audio clip is how many samples per second. so if it is 44.1khz, which i believe computes to 44,100 samples in 1 second of audio. for DVD's or 48khz it is even more and some go to 96khz and beyond.

so if you look at the big picture, you'd have to have an offset of +/- 44100 to miss one second of audio. (again, this is how i understand it to be, i'm certainly no audio engineer). soooo... ultimately, i think that correcting such a small offset should ultimately have pretty much no effect on the track. (only at a very small digital level). this would be for ripping a single WAV file... as for ripping into multiple WAV files with gapless transitions, i'm honestly not sure how that works or doesn't work. maybe someone can enlighten us on that. i would assume if the offset was off by -628 (from where it should be) then you'd be 'adding' fake samples at the start of track 1, and subtracting 628 samples from the end of the track, making the next track start prematurely / before it was intended to. as mentioned though... with the human ear... fractions of a second... milliseconds.. the ear is not even going to notice any difference, audibly.

that is the best i can explain it with what i know... if anyone can clear up the offset thing when ripping multiple tracks on a gapless cd or whatever... that confuses me even.. sorry!

[edit]
greynol: i pretty much agree with what you said, as i understand it.. (some wording was confusing to me). of course the #1 way to do this is go out, buy the CD, find the correct offset for the drive you will rip your CD with, enter that offset into your ripping program, and have away. i am not promoting piracy, i am simply acknowledging reality and the fact that people do download CD's and was citing an example of why/how things could get obfuscated.

i have ripped my entire music collection of hundreds of CD's, and out of those.... most have perfect AR matches... say 95% have at least 2-3 matches on the same offset. Then again, there are a few dics that I own, physically have put the disc in and ripped it with the same settings, and i have gotten NO matches on my offset... but matches on other ones. then you get into the whole idea of pressings and this or that.. and how do we know the original submissions were accurate to begin with, that whole point is -- as the match numbers go up, so does your ability to say this is indeed a correct rip.... a rip that matches .... 32 other people's rips.

if you download something, you never know if they have adjusted the offset... by how much... what methods of extraction they used, etc. which is exactly why i was saying that downloading something was unreliable (not to mention illegal).

but anyway.. you can read more about what i meant in the above post... to clarify some of what i said.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #710 –
Quote from: greynol on
Doing so will possibly throw out more data, though what might be thrown out is likely nothing more than a very low-level signal found at the edge of the disc.


But actually there is no chance of losing something of the true audio track data when messing with offsets?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #711 –
Quote from: SpaceAgeHero on
But actually there is no chance of losing something of the true audio track data when messing with offsets?

What you just quoted from me just said there was a chance of losing something when messing with offsets.  Even if it is just low-level noise, it is still audio data that existed on the CD.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #712 –
I have another question. Apparently AR does not count any higher than 200 for a certain pressing / offsetted version.
Is that normal?

Code: [Select]
Track	[ CRC    ] Status
 01	[ff1a33cd] (200/1189) Accurately ripped
 02	[a96740a2] (200/1202) Accurately ripped
 03	[de29bb78] (200/1205) Accurately ripped
 04	[db7903f4] (200/1192) Accurately ripped
 05	[021e266a] (200/1197) Accurately ripped
 06	[39389339] (200/1202) Accurately ripped
 07	[4937bb12] (200/1209) Accurately ripped
 08	[61e58ede] (200/1190) Accurately ripped
 09	[227c62b6] (200/1188) Accurately ripped
 10	[ad30491c] (200/1194) Accurately ripped
 11	[ae4764f5] (200/1185) Accurately ripped
 12	[9a53b280] (200/1178) Accurately ripped
Offsetted by -2594:
 01	[783bf666] (15/1189) Accurately ripped
 02	[f5ea371d] (15/1202) Accurately ripped
 03	[30c86498] (15/1205) Accurately ripped
 04	[130b52bc] (15/1192) Accurately ripped
 05	[e81c5a10] (15/1197) Accurately ripped
 06	[eba5b54a] (14/1202) Accurately ripped
 07	[d0ec685a] (15/1209) Accurately ripped
 08	[88e12a9a] (15/1190) Accurately ripped
 09	[5ae46ce9] (15/1188) Accurately ripped
 10	[30ef2018] (15/1194) Accurately ripped
 11	[17d63435] (15/1185) Accurately ripped
 12	[f81b9f66] (15/1178) Accurately ripped
Offsetted by -2147:
 01	[de72532f] (05/1189) Accurately ripped
 02	[fff75ae6] (04/1202) Accurately ripped
 03	[6302811d] (04/1205) Accurately ripped
 04	[858169ec] (03/1192) Accurately ripped
 05	[04f6789e] (04/1197) Accurately ripped
 06	[3140cbbc] (04/1202) Accurately ripped
 07	[7f3b3fa6] (04/1209) Accurately ripped
 08	[2566075f] (04/1190) Accurately ripped
 09	[0699f2d8] (04/1188) Accurately ripped
 10	[3a0573d0] (03/1194) Accurately ripped
 11	[6ef2c9d5] (04/1185) Accurately ripped
 12	[a92e5d69] (03/1178) Accurately ripped
Offsetted by -1930:
 01	[d6e9da2c] (111/1189) Accurately ripped
 02	[21321107] (112/1202) Accurately ripped
 03	[18fede85] (110/1205) Accurately ripped
 04	[89dda9d7] (106/1192) Accurately ripped
 05	[bc6101a0] (108/1197) Accurately ripped
 06	[77c17916] (111/1202) Accurately ripped
 07	[0c2cd540] (112/1209) Accurately ripped
 08	[ae55bc2d] (107/1190) Accurately ripped
 09	[3b74a5f0] (106/1188) Accurately ripped
 10	[2ec8645c] (109/1194) Accurately ripped
 11	[9c19dd35] (108/1185) Accurately ripped
 12	[0c50a99e] (105/1178) Accurately ripped
Offsetted by -1466:
 01	[a69a5291] (153/1189) Accurately ripped
 02	[3f6d59ba] (158/1202) Accurately ripped
 03	[2969b033] (163/1205) Accurately ripped
 04	[c2f02f6a] (163/1192) Accurately ripped
 05	[b59baeff] (162/1197) Accurately ripped
 06	[d77b92cb] (162/1202) Accurately ripped
 07	[a2c2fbfe] (163/1209) Accurately ripped
 08	[8f940e06] (160/1190) Accurately ripped
 09	[e7c82b9c] (154/1188) Accurately ripped
 10	[765b3ccc] (161/1194) Accurately ripped
 11	[8c932b35] (153/1185) Accurately ripped
 12	[dcbfc02e] (156/1178) Accurately ripped
Offsetted by -1060:
 01	[f21d9326] (11/1189) Accurately ripped
 02	[f90d74b9] (12/1202) Accurately ripped
 03	[efcbf98a] (13/1205) Accurately ripped
 04	[28eb1130] (13/1192) Accurately ripped
 05	[4ec1f548] (13/1197) Accurately ripped
 06	[0cc94d81] (13/1202) Accurately ripped
 07	[b426db23] (12/1209) Accurately ripped
 08	[45a42fa6] (12/1190) Accurately ripped
 09	[e01483f9] (13/1188) Accurately ripped
 10	[1080e060] (13/1194) Accurately ripped
 11	[9efd4f75] (13/1185) Accurately ripped
 12	[3320f3ec] (13/1178) Accurately ripped
Offsetted by -994:
 01	[072ed398] (200/1189) Accurately ripped
 02	[fe12781b] (200/1202) Accurately ripped
 03	[6ddb1e82] (200/1205) Accurately ripped
 04	[d0301746] (200/1192) Accurately ripped
 05	[0852cfe4] (200/1197) Accurately ripped
 06	[86374e04] (200/1202) Accurately ripped
 07	[18d59a8e] (200/1209) Accurately ripped
 08	[7c13429b] (200/1190) Accurately ripped
 09	[fc3ce3de] (200/1188) Accurately ripped
 10	[cadc3efc] (200/1194) Accurately ripped
 11	[b6290c35] (200/1185) Accurately ripped
 12	[164b3ca6] (200/1178) Accurately ripped
Offsetted by -933:
 01	[97eca216] (08/1189) Accurately ripped
 02	[0c41ed63] (08/1202) Accurately ripped
 03	[f0afc05c] (07/1205) Accurately ripped
 04	[df73781d] (07/1192) Accurately ripped
 05	[945eeed4] (07/1197) Accurately ripped
 06	[bcce0c24] (08/1202) Accurately ripped
 07	[81a9b79b] (08/1209) Accurately ripped
 08	[ea2c1d73] (08/1190) Accurately ripped
 09	[53a39694] (08/1188) Accurately ripped
 10	[40d43a17] (08/1194) Accurately ripped
 11	[09a2ed15] (08/1185) Accurately ripped
 12	[77c3c5af] (08/1178) Accurately ripped
Offsetted by -669:
 01	[25ebab40] (06/1189) Accurately ripped
 02	[56dc7eb9] (06/1202) Accurately ripped
 03	[d28e6488] (06/1205) Accurately ripped
 04	[3ced2f03] (06/1192) Accurately ripped
 05	[c5a9312a] (06/1197) Accurately ripped
 06	[ae37afe3] (06/1202) Accurately ripped
 07	[c551eb3e] (06/1209) Accurately ripped
 08	[fcaa8526] (06/1190) Accurately ripped
 09	[358cb9b9] (06/1188) Accurately ripped
 10	[d0b828e5] (06/1194) Accurately ripped
 11	[6651e015] (06/1185) Accurately ripped
 12	[046ce897] (05/1178) Accurately ripped
Offsetted by -293:
 01	[23ef3bed] (23/1189) Accurately ripped
 02	[3bdc59ac] (23/1202) Accurately ripped
 03	[dff7af08] (23/1205) Accurately ripped
 04	[d759fcc4] (23/1192) Accurately ripped
 05	[1acdb741] (23/1197) Accurately ripped
 06	[28850cef] (23/1202) Accurately ripped
 07	[f686f549] (23/1209) Accurately ripped
 08	[71fb3196] (23/1190) Accurately ripped
 09	[0f534a80] (23/1188) Accurately ripped
 10	[2252eb2f] (23/1194) Accurately ripped
 11	[e290dd15] (23/1185) Accurately ripped
 12	[50a39e2f] (23/1178) Accurately ripped
Offsetted by -287:
 01	[e4c5601b] (02/1189) Accurately ripped
 02	[bf9aaa5a] (02/1202) Accurately ripped
 03	[c2395d28] (02/1205) Accurately ripped
 04	[102c7e50] (02/1192) Accurately ripped
 05	[3fbc2af3] (02/1197) Accurately ripped
 06	[be957160] (02/1202) Accurately ripped
 07	[3fc67275] (02/1209) Accurately ripped
 08	[8a99b981] (02/1190) Accurately ripped
 09	[8b50c28b] (02/1188) Accurately ripped
 10	[d3fc91f8] (02/1194) Accurately ripped
 11	[cd664b55] (02/1185) Accurately ripped
 12	[1f78ea9d] (02/1178) Accurately ripped
Offsetted by -275:
 01	[7aa357f0] (02/1189) Accurately ripped
 02	[a1d728bd] (02/1202) Accurately ripped
 03	[86bcb968] (02/1205) Accurately ripped
 04	[51a8ba2b] (02/1192) Accurately ripped
 05	[333f9584] (02/1197) Accurately ripped
 06	[e8d89647] (02/1202) Accurately ripped
 07	[c39c82f5] (02/1209) Accurately ripped
 08	[07dfd570] (02/1190) Accurately ripped
 09	[2f9e38f5] (02/1188) Accurately ripped
 10	[37d8deb0] (02/1194) Accurately ripped
 11	[a31127d5] (02/1185) Accurately ripped
 12	[bd238379] (02/1178) Accurately ripped
Offsetted by -269:
 01	[57e5b427] (200/1189) Accurately ripped
 02	[fcb454ba] (200/1202) Accurately ripped
 03	[68fe6788] (200/1205) Accurately ripped
 04	[d6e44acb] (200/1192) Accurately ripped
 05	[3f80d202] (200/1197) Accurately ripped
 06	[4fd075a6] (200/1202) Accurately ripped
 07	[8e62db7e] (200/1209) Accurately ripped
 08	[651e9574] (200/1190) Accurately ripped
 09	[2bcc0f21] (200/1188) Accurately ripped
 10	[ea34849c] (200/1194) Accurately ripped
 11	[8de69615] (200/1185) Accurately ripped
 12	[8bf8cfe7] (200/1178) Accurately ripped
Offsetted by -36:
 01	[b164b641] (09/1189) Accurately ripped
 02	[cabc1f16] (09/1202) Accurately ripped
 03	[909fa6b8] (09/1205) Accurately ripped
 04	[074c16c5] (09/1192) Accurately ripped
 05	[35554345] (09/1197) Accurately ripped
 06	[930599b2] (08/1202) Accurately ripped
 07	[9163b790] (09/1209) Accurately ripped
 08	[cd982676] (09/1190) Accurately ripped
 09	[6e469845] (09/1188) Accurately ripped
 10	[9ae27fe6] (09/1194) Accurately ripped
 11	[2d46cf75] (09/1185) Accurately ripped
 12	[c153e7ec] (09/1178) Accurately ripped
Offsetted by 260:
 01	[9feea860] (16/1189) Accurately ripped
 02	[bc51fc97] (15/1202) Accurately ripped
 03	[7ff28a38] (15/1205) Accurately ripped
 04	[468cf5f5] (15/1192) Accurately ripped
 05	[a050997d] (15/1197) Accurately ripped
 06	[62064d29] (16/1202) Accurately ripped
 07	[5ac401a5] (16/1209) Accurately ripped
 08	[d76369d8] (14/1190) Accurately ripped
 09	[fef74b5e] (15/1188) Accurately ripped
 10	[99d335b7] (16/1194) Accurately ripped
 11	[6e680e75] (15/1185) Accurately ripped
 12	[f26ea274] (14/1178) Accurately ripped
Offsetted by -1062:
 01	[9acb0d77] (00/1189) No matches
 02	[a4d77b64] (02/1202) Partial match
 03	[4fc98f44] (02/1205) Accurately ripped
 04	[9c51174e] (02/1192) Partial match
 05	[b08bc1de] (02/1197) Partial match
 06	[015b10a6] (02/1202) Partial match
 07	[6306028c] (02/1209) Accurately ripped
 08	[cb1fa93c] (02/1190) Partial match
 09	[4e8b90eb] (02/1188) Partial match
 10	[311c632e] (02/1194) Partial match
 11	[50b62ab5] (02/1185) Accurately ripped
 12	[98d9da72] (00/1178) No matches
Offsetted by -263:
 01	[a93820d1] (00/1189) No matches
 02	[47c272fc] (00/1202) No matches
 03	[4b4015a8] (02/1205) Partial match
 04	[4e0ebcb9] (00/1192) No matches
 05	[401c0e52] (00/1197) No matches
 06	[45b432c3] (00/1202) No matches
 07	[337a36e6] (00/1209) No matches
 08	[055ab6f5] (00/1190) No matches
 09	[286504c8] (00/1188) No matches
 10	[9cef2a6b] (00/1194) No matches
 11	[78bc0455] (00/1185) No matches
 12	[5ace1c55] (00/1178) No matches

Track	[ CRC32  ]	[W/O NULL]	
 --	[3BBB0CA0]	[355759D8]	
 01	[0F7402B6]	[F6947445]	
 02	[081D405C]	[B5CCBB6E]	
 03	[69B3F7C7]	[7607E5EC]	
 04	[8E90AE6B]	[18E99A29]	
 05	[D84DB09D]	[E9414728]	
 06	[096618CA]	[D89ECD71]	
 07	[8344C953]	[D9032AAF]	
 08	[C77AC9BD]	[09EB9510]	
 09	[4E46DDD6]	[4A9FBB20]	
 10	[0E3F6A5B]	[DB270654]	
 11	[1E10CC16]	[12401A96]	
 12	[4679A4F7]	[F31A7A4E]

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #713 –
Quote from: Chinch on
sure, the information is usually silence/null samples.

Have you actually conducted a study or are you just guessing?

Quote from: Chinch on
as the match numbers go up, so does your ability to say this is indeed a correct rip

Except for rare circumstances dealing with firmware bugs or manufacturing defects that exploit problems with specific chipsets and/or ripping programs, a high confidence guarantees you nothing over a low confidence.  It's my belief that the ability to verify against more than one pressing is more meaningful than the level of confidence of any of those pressings.  This includes the potential for situations involving manufacturing defects and bugs with software or firmware.

Quote from: Chinch on
i would assume if the offset was off by -628 (from where it should be) then you'd be 'adding' fake samples at the start of track 1, and subtracting 628 samples from the end of the track, making the next track start prematurely / before it was intended to. as mentioned though... with the human ear... fractions of a second... milliseconds.. the ear is not even going to notice any difference, audibly.

Actually it can very easily be audible depending on where the cut takes place.  Perhaps it would help for you to contemplate the question I posed at the end of my post. (EDIT: and no, the track doesn't have to be cut by thousands of samples for it to be audible.)

Another question would be that if applying an offset to the data is not audible, then why bother in the first place?  So that the rip will match an entry in the AR database?  Is the exercise of using a program to verify them against alternate pressings not enough?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #714 –
Quote from: SpaceAgeHero on
I have another question. Apparently AR does not count any higher than 200 for a certain pressing / offsetted version.
Is that normal?

Yes.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #715 –
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
So how come all these different offsetted versions are in the database anyways?
Must they all not just be from different pressings?
Basically a true accurate rip would be ripped at zero offset?
How am I supposed to tell which offsetted version is the true accurate one when all shown versions have just relative offsets to other rips? As far as I understand now that can only be guessed by the most popular rip.

When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #716 –
sorry, i don't have the time to fully read through and respond yet, but i was going to cite this info i just pulled up:

A CD audio disc is divided into sectors. Each sector holds 1/75 seconds of        audio, or 588 samples at 44100 samples per second, or 2352 bytes. If the size        of a WAV recording is not a multiple of 588 samples, the recording software        will fill the remainder of the sector with zeroes. If you have a continuous        recording (live), you'll hear a short click in between two songs, as a result        of the padding zeroes. To prevent this, the program always cuts on 588 sample        borders, so two adjacent songs will have no clicks in between.

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).

since 99% of the time there is silence or null/0 samples before the first track and after the last one, i believe in this case (single wav + cue) could be identical to a rip using a different offset. for example... if the first 100 samples of a CD are nothing but zero padding/null or even "silence", if you are off by 6 samples, either way it can be the same result, since EAC can be made to "fill missing samples with silence"... if on the disk in those same 6 samples, it was actually silence anyway, then you in effect have used an incorrect offset but achieved an identical result as if you had used the right one.


all in all, it's a pretty moot point... as i mentioned... i advise to rip only to single wav/image rather than file-per-track. 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)... you could go pretty low level with it, but the simple point is... in response to one of your questions -- what is the purpose of offset correction? just to make it match a set of results? -- actually yes, IMO, this is what most people use it for... so it matches up with something so they can say ok it matches, it's accurate. if it matches, it matches. CRC's are going to differ if the data is not identical. (yes, again for the super super techie, it's POSSIBLE that two different files could calculate to the same CRC value... but let's be realistic). the more proper usage of offset correction would be if i ripped 20 cd's on my drive... then realized i didn't put in the correct offset... on mine it's +6. rather than re-rip 20 cd's, since i KNOW what offset they SHOULD have been ripped using, I can use this validated knowledge to make this correction... it wouldn't be a guess.. it would be what the discs should have been read as anyway.

even so, in either instance, you could possibly end up with identical match still, or a different one. there is the possibility (but it is unlikely) that you will be replacing your missing samples with the wrong thing.

in the end, offset correction = losing data somewhere. either at the front or the tail end, depending if the offset is +/-. when you're correcting, you're ASSUMING that the missing samples were a certain value (silence/null values)... most of the time, the guess is correct, and you end up with matching CRC's because of the simple fact that CD's generally never start the audio right at sample 0 or end the audio at the very last sample. there is a bit of lag in when the actual AUDIO begins on the physical layout, and where the physical layout itself begins. here's your test... take a cd... rip a wav.. put in an offset you know is wrong. you know your correct one... then take a look at those x samples that were originally not there or were spilled over into. that can give you your answer.. if you need to get a dang hex editor out and look at it byte per byte.

i guess i've kind of made my side of the argument, i believe we are thinking the same thing, but our expression of those ideas in writing sound different.. who knows... i can't say i'm 100% right, and neither can you or the next guy just by opinion and objective knowledge. either way, it's not a point worth getting frenzied over... buy the CD's.. make sure you have the correct offset for your drive in there, then you're pretty much good to go.

this is why with the exception of a few strays, my rips always match up with at least one, usually multiple sets/pressings.. often all offsets match. can i feel confident when i rip my own cd with the correct settings then get results from AR/CueTools saying that my rip is 167/167, all offsets matching? yes, absolutely.

AR is not to 100% absolutely prove without a shadow of a doubt your audio rip is a bit for bit copy of that CD.... it's yet another layer of authentication/validation that it is right. i mean..... if you do a test&copy and get the same CRC result both times, you get results that match .... xx amount of other people who have copied the same cd....... you can sleep well enough at night.... you can pretty much say that with 99.9% accuracy your rip is perfect as anyone else's. i'm cool with that. i try to "never say never" cause there are always exceptions and those super rare 1 in a million things that can happen to prove to us that .... NEVER?? ... psh..  never loves to prove people wrong 

oh... btw.... i will honestly admit that i'm not 100% positive on the difference between null samples, zero'd samples and "silence". i assume that null = 0's as bit data, so null and zero would seem to be the same to me..(though technically something that is "null" doesn't exist, but i'm pretty sure it means 0's). as for silence... what is silence? if it is well below your physical threshold/capacity to hear, is it silence? it's silent to you, since you do not have the capacity to perceive it.... but there's still noise there....................... or is there?........... maybe it's all a dream........ *brain spasm* just wanted to get all philosophical on ya arses to make things a little lighter. everything is relative, my friends.. a person who is 'color blind' may look at blue and say it's orange..... you laugh and go... you idiot. it's blue.  what is blue? a wavelength of light..... what makes that wavelength of light "blue"??? --- our perception.. and perception is relative -- therefore can reality be relative and not absolute?  to each individual, their perception is "reality". who is right? nobody can ever know for sure........

man. 10 minutes ago we were talking about ripping CD's.... now i'm questioning my own existence... haha

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #717 –
Quote from: SpaceAgeHero on
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
Sure, though it's possible to submit results from CD-R an I think it's possible for results to come from an incorrectly configured drive that is not in the database and that these results can be available if it either has matches or there are no other entries with matches for the same disc ID.

Quote from: SpaceAgeHero on
So how come all these different offsetted versions are in the database anyways?
Different manufacturing runs often produce versions with different offsets, assuming, of course the TOC stays the same.

Quote from: SpaceAgeHero on
Must they all not just be from different pressings?
Your use of the word "not" is making this difficult for me to understand, but I think I've explained it.

Quote from: SpaceAgeHero on
Basically a true accurate rip would be ripped at zero offset?
No.  Notwithstanding the debate over what is the correct reference, there is little if any reason for one to conclude that one pressing is more true than another.

Quote from: SpaceAgeHero on
As far as I understand now that can only be guessed by the most popular rip.
I tried to dispel this notion.  Oh well.

Quote from: SpaceAgeHero on
When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?
AR can keep multiple checksums (which are not CRCs, BTW) for each track per disc ID.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #718 –
Quote from: Chinch on
so that may be an example of how an offset could screw with things.
Actually, no.  Offsets result in data shifting, they do not change the lengths of tracks unless you tell your ripping program not to pad missing samples with silence which will only affect either the first or last track on the disc.  Your confusion with this is not helping progress the discussion.
Quote from: Chinch on
all in all, it's a pretty moot point... as i mentioned... i advise to rip only to single wav/image rather than file-per-track.
I would advise that people ignore your advice.  Sorry that this sounds harsh, but you appear to be getting in way over your head.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #719 –
Quote from: SpaceAgeHero on
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
So how come all these different offsetted versions are in the database anyways?
Must they all not just be from different pressings?
Basically a true accurate rip would be ripped at zero offset?
How am I supposed to tell which offsetted version is the true accurate one when all shown versions have just relative offsets to other rips? As far as I understand now that can only be guessed by the most popular rip.

When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?


between the post i just made, and this one you just made... i think you may have destroyed my brain..... seriously hahah.. you are very inquisitive... but there's nothing wrong with that... but you sure have given me a mind****!

let's get simple again... CD's are made in batches, or pressings. say a factory gets an order for 10,000 copies of a CD. they get the master plates, and they duplicate every CD of that master (simply put.. they can only make so many copies before they begin to wear out but that's outside the point)...... that's a batch.  the audio data on those pressings starts at a certain spot.

later on, they run out... we need another 10,000... they have another factory whip them up another batch. for whatever reason or another, the audio data can be slightly off/different, though it is the same CD technically.... i suppose becauses of different pressing equipment, this or that... there's always some margin for small error.

you're going to possibly get two different CRC results when ripping these two pressings with the same burner, etc.

then you have some pressings or sets that do not match... for instance, one version may have a hidden track after 3 minutes of silence on a re-release or special edition... in that case, you'll get matches possibly on all of the tracks except the last one.

there are many reasons why any two of the same "album" can truly have different offsets.... and they can both be right. there may really be 30 people out there with a copy of the disc that came from batch X where the offset, to THEM is ZERO... given an accurate rip. to you, with a different pressing, that had a slight difference in where the audio started because it was made at a different time or pressing plant -- will also have a ZERO offset if your settings are right.

-- and you both have accurate rips. there is no such thing as a single correct rip... you just see theirs as being "X" samples off from yours.... that's why they call them offsets...... cause the start of their data is OFFSET from yours by so many samples. offset essentially meaning "the difference" in reference points. just imagine it like this... two different pressings..... both physical... true blue factory copies....

disc one:


00000000000000101010001111001100101001110110100110101
                                    ^ start of the audio data

disc two:

00000000000000000000000000010101010010101010101001111
                                                                        ^ start of the audio data


in this example, if disc one is ripped and verified against disc two... disc two will show up as a match, with an offset of +13, because it has the same audio fingerprint... it's just shifted up 13 places from the first... or offset by +13 samples.

likewise, if the owner of disc two were to rip his copy and verify it against the database.... disc one would show up as an (offset) match as well... but his would show their rip is -13 offset... because it starts 13 positions before theirs does on the physical cd.

i hope that makes it more clear for you to understand... by the way that may not be perfect, i roughly counted 13 more 0's before disc two kicked in. don't take my crappy drawings as true technically.... it is just a visual example. sometimes things are easier  when they are visual.

in an ideal world, all drives and lasers would start at the same spot on the disc, every time. but they are not perfect, and that is why we have drive offsets as well. because of calibration or mechanical difference:

drive one may begin to read the disc physicaly at position 3.

0000000000000
    ^--- laser doesn't exactly start on the ACTUAL beginning of the disc data, it's positioned a little ahead.... ack. we need to tell it to back up... this drive needs to have an offset of -3 to tell it "hey... you're starting late... there's data that's supposed to be back there and you didn't even catch it... better put something there......... what was there? i dunno..... probably 000's.... that's what 99% of CD's start with... some zero's... so instead of writing the data as ???000000 i'll write it out as 000000000. (luckily, this matches what was truly missed during the read, so the track is actually identical still!)

as a counter example, drive two may actually read BEFORE the disc even starts, for example

------------00000000
  ^-- begins reading before the data even begins! in this case, the drive would have to have a positive offset applied to it, that is, a correction applied to it to tell it to not start reading any data until after, say, 7 positions. so when the drive begins to read this disc... it will ignore the first 7 bits it reads... THEN it will start copying the data. by giving it an offset, (or an offset correction, more specifically) we have eliminated it from reading garbage from the first 7 positions. for all we know there could have been an imperfection on one of those first 7, which the drive might have accidentially read as a 1... when there is truly nothing there... it was an error. without telling it the offset, it would have picked up that incorrect garbage bit, and thrown the whole thing off... and your starting point would be all jacked up and everything may just be plain wrong after that mishap.

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. that's ok though, because in reality, this stuff can and does get quite technical... and can get confusing very quickly.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #720 –
I haven't read all the recent discussion so I am only answering SpaceAgeHero's post:

Quote
I thought AccurateRip value submission was only possible if the disc drive had the right offset correction applied.
True
Quote
So how come all these different offsetted versions are in the database anyways?

These offsets are applied by the burner/writer of the music compagnie.
Quote
Must they all not just be from different pressings?

True, they are. (See previous answer)
Quote
Basically a true accurate rip would be ripped at zero offset?

Wrong, as long as you can detect it, the offset doesn't matter.
Quote
How am I supposed to tell which offsetted version is the true accurate one when all shown versions have just relative offsets to other rips? As far as I understand now that can only be guessed by the most popular rip.

There is no "true accurate version" your whole concept is flawed & due to a missunderstanding of offsets. The "most popular rip" is not more accurate, it is only ... the most popular.
Quote
When offsets can actually be real data why would AccurateRip still say its accurate when offset correction is applied. Wouldn't AccurateRip notice a changed CRC value?

The offset itself cannot be data, it's a word abuse. The offset is a positive or negative sample numbers. Think of it as a cutpoint, a cutpoint doesn't have a lenght. Think of it as if it didn't have a lenght: then the offset become nothing more than a positive or negative shift of the cutpoint between song.
(NOTE: This is a simplification for you to understand, the offset doesn't shift the cutpoint (the cutpoints are static within the cue sheet no matter the offset), it shift the whole audio data, but in a way the result is the same, it modify the splitpoint between songs)
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.
As soon as you shift the data cutpoint so much that you fall in the middle of audio data (even not listenable noise data) then the CRC will not match.

So, as long as all tracks are AR2 within the same offset, different pressings with only a different offset are in fact the exact same data, that's why AR count all these rips as accurate no matter the offset.

If between 2 pressings with 2 different offsets all song are accurate except 1, it means the offset was small enough to not fall right in the middle of data, for all songs EXCEPT the one that is suddenly not accurate. In this case you shouldn't correct offset.

Personnaly I correct offset to most popular IF & only IF all tracks (100% in advanced settings) are AR2 (minimum) within the same offset for the 2 pressings (My rip & the Target (Most popular)). Don't correct offset has long has you don't understand them fully you can lose data if you do a misstake, specially with big negative offset.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #721 –
Okay guys. Thank you very much for your time and all this interesting information.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #722 –
Quote from: greynol on
Quote from: Chinch on
so that may be an example of how an offset could screw with things.
Actually, no.  Offsets result in data shifting, they do not change the lengths of tracks unless you tell your ripping program not to pad missing samples with silence which will only affect either the first or last track on the disc.  Your confusion with this is not helping progress the discussion.
Quote from: Chinch on
all in all, it's a pretty moot point... as i mentioned... i advise to rip only to single wav/image rather than file-per-track.
I would advise that people ignore your advice.  Sorry that this sounds harsh, but you appear to be getting in way over your head.


i'm afraid that you may be confused in saying that i'm feeding him lies and false information. i'm not getting in over my head, i understand that an offset is a relativity in position in the physical sector layout on a disc. as i clearly demonstrated in my last post there, both verbally and visually... the concept of what an offset is, how it is relative, WHY it is relative to each drive and disc pressing.....

please don't tell me that i don't understand the concept of an offset.i may not know the low-level technical details of the format, how it is encoded exactly, but i do understand the general ideas.


i was an assembly language programmer for 3 years... where i had to calculate and implement offsets to read/write values from memory every single day... i understand what offsetting means, and relative positioning, indexing of data fields... it's like telling an electrician that he doesn't understand what alternating/direct current, volts, amps, etc are.

so i'll end this here and i think you should as well, and we will let other people come into the discussion and give them a chance to participate and give their own understanding of what is right and what is not.

i don't think they'll call me an idiot who doesn't have a clue... like you basically have. we will agree to disagree... or at least i will. we have dissenting opinions.... good. that makes for good discussion... otherwise the boards would be boring if everyone was just like "yeah.. you're right. that's right what he said. topic closed." debate is good, argument is not... so i am stepping out of this one and letting things cool down and give some others a chance to respond to the probably now VERY confused SpaceAgeHero. they've got me trying to help out and clear up some of their questions, and i'm making an effort to help this person out, and you're just coming behind me saying no that's wrong. i'm afraid you're confused. nope, now you're feeding false information, you don't have a clue what you're talking about.....

instead of antagonizing, how about you put in the time and effort i have into explaining to this poor soul these concepts. i want to see you explain to SpaceAgeHero how it works if i'm wrong. show me that i'm wrong... don't just tell me. if you prove me wrong... by all means i will swallow my pride and say you know what... you got me. you were right. so i now offer the stage to you and the others to ANSWER their question, rather than criticize my responses.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #723 –
Sorry but throwing out extraneous information about sector boundaries doesn't give me much confidence that you understand what an offset is, or how it relates to this discussion.

CUETools versions 1.9.5 through 2.1.5 (current)

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

According to Spoon accuraterip database is supposed to be updated every 2 or 3 months so it is likely that it will be updated sometime during this month. Is there any chance that we would have a new cuetools version at the same time the database gets updated  ... or am I dreaming wide awake ?