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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2675 –
I'm a new CUETools user.

First of all:
Thank you very much for this great tool, CUETools. It's really awesome!

Secondly:
I have a rip of which I know that it's not a perfect rip, as no offset correction was
used although an offset correction of +667 should have been used for a perfect rip.

I tried to turn this rip into a perfect rip, by first of all applying CUETools
encode (fix offset) function to it. I will show the result at the end of this
posting.

I've expected, that this causes 3 things:
- change in offset from 0 to +667

and as a logical consequence of this:
- the first 667 samples of the rip get cut off
- after the last sample of the rip a space in size of 667 samples arises, which will get filled up by null samples/silent samples, so that the complete length of the rip stays the same

Then, judging by the CUETools log file, I thought one can decide, if the rip by
this change already is perfect or not and needs a repair operation for it:
I thought, when accuraterip verifies the result as accurately ripped,
the rip turned into a perfect rip, and if accurate rip says the result
'don't match' then not. And in the latter case, if additionally also CTDB says
that the rip has 'errors' and there is 'repair data' in the CTDB in order
to fix it, that then one can do a second CUETools run where one applies 'repair' function
to the rip with fixed offset and then by this hopefully finally turned the rip
into a perfect rip, indicated by the respective CUETools log file where accurate rip now
says that the rip is 'accurately ripped' and also CTDB considers the rip to be without flaws.

In case the rip turned into a perfect rip just by the 'fix offset' function, so without
a second run for applying 'repair' function, I would have explained that to myself by
assuming, that the cutted away 667 samples were 667 additional null samples/silent samples
generated by missing offset correction and attached before the rip without offset correction,
anyway, so that cutting them away is totally fine, and that in case one had made a rip with
necessary offset correction, then the last 667 samples of the perfect rip would have been
null samples/silent samples, anyway, so that adding 667 null samples/silent samples
to the end of the rip without offset correction is also just fine.

So much to my understanding, now the CUETools log file of the first CUETools run,
the 'fix offset' run:

Code: [Select]
[CUETools log; Date: 23.05.2015 11:40:06; Version: 2.1.5]
Pregap length 00:00:33.
Offset applied: 667
[CTDB TOCID: pEqv9TiawaE1tmQwqS4BRRoonrY-] found.
Track | CTDB Status
  1   | (7/7) Accurately ripped
  2   | (7/7) Accurately ripped
[AccurateRip ID: 0000c818-000211c7-0901ba02] found.
Track   [  CRC   |   V2   ] Status
 01     [acc75a05|0dbc29d1] (43+23/95) Accurately ripped
 02     [f11833ee|5773840c] (43+23/95) Accurately ripped
Offsetted by -1015:
 01     [f3b003d9] (11/95) Accurately ripped
 02     [cd25a9b4] (11/95) Accurately ripped
Offsetted by -669:
 01     [a5e7e666] (05/95) Accurately ripped
 02     [4093b297] (05/95) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   99,9 [CFAB0DE2] [42E1D8DC]   CRC32   : offset -667
 01   99,9 [1672060F] [7EEB2F51]           
 02   99,8 [2D84EB79] [CFAA0A58]


My problem with this result is, that to me it doesn't make sense:
The CUETools log file tells me that offset correction of +667 was applied,
but to my understanding this actually can't happen without the other
2 things mentioned above:
Firstly cutting the first 667 samples of the rip, and secondly,
adding 667 null samples/silent samples after the end of the rip.
So, what i was expecting and what is just logic to me is, that
the CUETools log file not only contains the line 'Offset applied: 667', but also
additionally the lines 'Truncated 667 extra samples in some input files'
and 'Padded some (667) input files to a frame boundary', but it
only contains 'Offset applied: 667' and not the other both mentioned lines.

CUETools log file tells me 'I've corrected offset without cutting or adding anything
regarding the rip', which for me sounds like 'I've took a shower but didn't
become wet'.
So, how come, that the both lines 'Truncated 667 extra samples in some input files'
and 'Padded some (667) input files to a frame boundary' are missing in the CUETools log file?
Can't wrap my mind around it.
I also tried to apply 'fix offset' function not only automatically, but
also manually, but the CUETools log file is the same in both approaches.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2676 –
If applying Offset correction to the input file(s) means you discard samples from one end of the rip and add null samples to the other end then why isn't 'Offset applied: xxx' sufficient?

CUETools reports "Truncated 4608 extra samples in some input files" only when it detects the presence of an extra 4608 samples at the end of one or more of the input files (that might be added by some FLAC encoders) and removes those extra samples.

CUETools reports "Padded some input files to a frame boundary" when one or more of the input files are missing samples and do not align on a frame boundary. 

Applying Offset correction to the file(s) does not make your rip any better and really isn't necessary.

Code: [Select]
Offsetted by -1015:
01     [f3b003d9] (11/95) Accurately ripped
02     [cd25a9b4] (11/95) Accurately ripped
Offsetted by -669:
01     [a5e7e666] (05/95) Accurately ripped
02     [4093b297] (05/95) Accurately ripped
All tracks "Accurately ripped" means your rip is fine.
If you want to verify your rip at a different offset simply put that value in the 'Offset' box under the 'Extra' section. The offset is applied to 'Verify' without changing the file(s). Just remember to put '0' (zero) back in the box when finished.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2677 –
Quote from: korth on
CUETools reports "Truncated 4608 extra samples in some input files" only when it detects the presence of an extra 4608 samples at the end of one or more of the input files (that might be added by some FLAC encoders) and removes those extra samples.

IIRC there was a setting in EAC when it adds 4608 samples to a track as a workaround for some buggy MP3 encoders.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2678 –
Quote from: korth on
If applying Offset correction to the input file(s) means you discard samples from one end of the rip and add null samples to the other end then why isn't 'Offset applied: xxx' sufficient?
That's a good point. I assumed it was not sufficient because of the existance of the other both ... and my understanding of it; that implicated incompleteness or something absurd in the described case. If the other both didn't exist, or I had the understanding of them,
like you've explained it, or if I found this explanation in the wiki documentation of CUETools, I basically wouldn't have considered 'Offset applied: xxx' insufficient.

Quote from: korth on
CUETools reports "Truncated 4608 extra samples in some input files" only when it detects the presence of an extra 4608 samples at the end of one or more of the input files (that might be added by some FLAC encoders) and removes those extra samples.
Ah, so this line refers to something else than fixing a rip like described.
Well, if this is the case, I surely can renounce this line. Problem solved half way. Thank you.

Quote from: korth on
CUETools reports "Padded some input files to a frame boundary" when one or more of the input files are missing samples and do not align on a frame boundary.
But isn't this only (!) the case, when you perform the fix offset function?
I think your explanation so far made it clear enough, that the missing of the "Truncated 4608 extra samples in some input files" line is not weird at all in the context of described procedure,
but I can't say that so far from the "Padded some input files to a frame boundary" line, even after reading this explanation; it still sounds to me like something, which existance and absense in the
CUETools log file of a 'fix offset' operation implicates incompleteness or absurdity. To make it more clear: If the adding of null samples/silent samples in the process of a 'fix offset' operation
already is implicated by the line 'Offset applied: xxx', then how comes, the line "Padded some input files to a frame boundary" exist in the first place? Isn't that redundant then?

Quote from: korth on
Applying Offset correction to the file(s) does not make your rip any better and really isn't necessary.
I guess that you're right in practice, but not when archive quality is the aim.


Quote from: korth on
Code: [Select]
Offsetted by -1015:
01     [f3b003d9] (11/95) Accurately ripped
02     [cd25a9b4] (11/95) Accurately ripped
Offsetted by -669:
01     [a5e7e666] (05/95) Accurately ripped
02     [4093b297] (05/95) Accurately ripped
All tracks "Accurately ripped" means your rip is fine.
If you want to verify your rip at a different offset simply put that value in the 'Offset' box under the 'Extra' section. The offset is applied to 'Verify' without changing the file(s).
But isn't the 'fix offset' function also applied for creating a new music file or new group of music files as an output, which has a different offset than the offset of the input file(s)?

Quote from: korth on
Just remember to put '0' (zero) back in the box when finished.
Where's the point in doing that, when one knows that the offset of the input file(s) is wrong, and the output file(s) is correct?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2679 –
Quote from: digitalharmonic on
But isn't this only (!) the case, when you perform the fix offset function?


No, it's not. You get the same message (and action) when you take a not-proper rip (one with either missing or redundant samples that do not correspond to a correct frame boundary) and simply encode it, without changing offset.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2680 –
Quote from: digitalharmonic on
If the adding of null samples/silent samples in the process of a 'fix offset' operation
already is implicated by the line 'Offset applied: xxx', then how comes, the line "Padded some input files to a frame boundary" exist in the first place? Isn't that redundant then?

"Padded some input files to a frame boundary" is reported when the INPUT file(s) are missing some samples and do not align on a Compact Disc Digital Audio frame boundary due to some type of damage or source material not from a CD.

Edit: Goratrix beat me to it.

Quote from: digitalharmonic on
I guess that you're right in practice, but not when archive quality is the aim.

The quality doesn't change but samples are discarded.

Quote from: digitalharmonic on
But isn't the 'fix offset' function also applied for creating a new music file or new group of music files as an output, which has a different offset than the offset of the input file(s)?

I was providing an alternate to misusing the 'fix offset' script to change the offset of the file(s) just to verify against the AR database.

Quote from: digitalharmonic on
Where's the point in doing that, when one knows that the offset of the input file(s) is wrong, and the output file(s) is correct?

Because if you don't return the value in the Offset box to '0' (zero) in the Extra section, the nonzero offset in that box will also be applied to future rips you verify or encode.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2681 –
Thank you for your answers, Goratrix and korth,
and thank you for your patience, korth.

So, the 'fix offset' function is just a verification thing and
can't be used as a tool, to create new music files with different offset,
and even if one could use it as this, it wouldn't make a difference
in terms of practice and archiving.
To be honest, that doesn't surprise me so much, as this notion of
changing offset of music files afterwards and in combination with the
repair function if necessary after that step repairing them sounded like magic ^^ ...

But what leaves me puzzled is the offset thing: If it doesn't matter like discribed,
then why all this hazzle exist around it with 'oh, you got to change offset to XXX !'
and so ?
I mean what you basically say is 'forget the offset thing while ripping and afterwards.
Even if one wants a perfect rip, it's a complete waste of time to deal with it.'

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2682 –
I didn't say 'fix offset' couldn't be used to create new music files with a different offset, I said it wasn't necessary to use the script to alter the files just to verify in the AR database (see pressings).

It isn't necessary to use the 'fix offset' script prior to running the 'repair' script either. The CTDB recovery record doesn't care about the offset.
Here's an [a href='index.php?act=findpost&pid=108678']example[/a] of when applying an offset could be helpful.
The correct 'read offset' is so everyone gets the same data, even when using different hardware. If the read offset wasn't set, it is similar to having a pressing that no one else has yet submitted to the AR database. Unless there is a problem with correct playback as in the example above, there's no real need to fix it. But if it makes you feel warm and fuzzy to correct the offset to what should've been set in the software then you'll just discard a few milliseconds from one end of the rip (also see the [a href='index.php?act=findpost&pid=819468']developer's comments[/a]).
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2683 –
Correct [a href='index.php?act=findpost&pid=892908']example[/a] link for previous post. (I must've entered a topic ID for a post ID).
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2684 –
Hello all! I have CUE Tools 2.1.4 installed in my system and I cannot find a way to uninstall it. I have looked in the folder where all the files are installed and I have looked under the Uninstall or Change a Program directory in Control Panel. None have an option to uninstall CUE Tools, which is a little frustrating. Please help!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2685 –
There is no uninstaller for CUETools. All u have to do is deletes it's folder

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2686 –
Indeed, when you installed it, you just unzipped it to a folder.

If you didn't delete the file user_profiles_enabled, then your settings are in
%appdata%\CUE Tools
%appdata%\CUERipper

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2687 –
korth, well, if it's like this I guess that I refrain from fixing offset and all that stuff I've mentioned before, because judging all of the feedback I wouldn't feel warm and fuzzy enough for doing it  ...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2688 –
Not sure if this is a known bug, but CUETools seems to refuse multiple apostrophes. Tried to AR-verify albums with the following directorynames (and corresponding album tags ...)

Belial {1994} ~ '3'
Judas Priest {1990} ~ Painkiller [3'']
Pretty Maids {1999} ~ Shape Edit. 3 'Bandlogo'
Skyclad {1999} ~ Shape Edit. 9 'Vintage Whine'

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2689 –
Quote from: Porcus on
Not sure if this is a known bug, but CUETools seems to refuse multiple apostrophes. Tried to AR-verify albums with the following directorynames (and corresponding album tags ...)


Nope, the album tags had a quotation mark ".  Which is an illegal filename character yes - but CUETools reacts even when I had not told it to use it in any output filename.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2690 –
Short question: Is there any way to make it visible in the documentation files (log file, accurip file, etc.) with what audio codec version one encoded ? I mean, that would come pretty handy for re-ripping old rips with FLAC 1.1.2, or so...

of course, I've already checked all program options and used a web search engine on that issue, but I couldn't find
anything...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2691 –
I've just started using CueRipper, and have encountered a disc which it seems to be unable to detect the gap information for, yet EAC was able to detect the gaps just fine. Does anybody know why this is happening, and if there is any way to help CueRipper detect the gaps?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2692 –
Also, is there any way to determine if CueRipper is able to detect the gap information prior to ripping a disc (as opposed to having to wait until it's finished ripping the CD and examining the log file)?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2693 –
Quote from: digitalharmonic on
that would come pretty handy for re-ripping old rips with FLAC 1.1.2


which is a nonsensical thing to do, if you really meant to write "re-ripping". FLAC is lossless, remember.

A media player (e.g. foobar2000) can tell which FLAC version a file is, and then you can convert using the tool of your choice (does fb2k transfer embedded album art by now?) - myself I got rid of my 1.1.x files to get rid of a few lines in 'selection properties' windows (less scrolling to get to mp3s ...).
However there seems to be no way - without reencoding - to tell what compression level was used.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2694 –
Hello.
In cuetools i need to add cover art with any name to files tags. Can i do this in batch mode?
I know about "Cover Art Files {string[] array}" settings but i try to add "*.jpg" or ".jpg" and it's not working. Maybe it's not possible to add jpg with any name?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2696 –
Quote from: LITBe on
Hello.
In cuetools i need to add cover art with any name to files tags. Can i do this in batch mode?
I know about "Cover Art Files {string[] array}" settings but i try to add "*.jpg" or ".jpg" and it's not working. Maybe it's not possible to add jpg with any name?

No wildcards. You can match name (cover.jpg), placeholder (%filename%.jpg) or combo (%album% cover.jpg, %artist% - %album%.jpg).
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2697 –
Quote from: ChronoSphere on
I'm currently running CUETools on WINE and it somewhat works (did not try CUERipper yet), but it's full of weird side effects. For example mounting /tmp as R:\ then attempting to access R:\ via CUETools results in  "The given path's format is not supported". Going via the internal Z: drive gives something similar: "Z:\tmp - the given path's format is not supported". foobar2000 can access the same folder on WINE just fine.


Regarding this issue, I was able to pinpoint what is causing it: if any of the files in the folder you are trying to browse contain invalid characters by NTFS definition (in my case, ':' in socket file names in /tmp), then CUETools cannot list anything and just spits out that message.
I would be eternally grateful if CUETools could ignore and simply not show invalid filenames instead.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2698 –
There is one thing I haven't understood about track CRC and AccurateRip. I have two different rips of the same CD, one correctly ripped, and the other not:

Correctly ripped:

Code: [Select]
[CUETools log; Date: 23/07/2015 12:03:24; Version: 2.1.5]
[CTDB TOCID: oIvFX8j3CpjAXxoaG80nqUK0sRI-] found.
        [ CTDBID ] Status
        [286d9cba] (5/5) Accurately ripped
Track | CTDB Status
  1   | (5/5) Accurately ripped
  2   | (5/5) Accurately ripped
  3   | (5/5) Accurately ripped
  4   | (5/5) Accurately ripped
  5   | (5/5) Accurately ripped
  6   | (5/5) Accurately ripped
  7   | (5/5) Accurately ripped
  8   | (5/5) Accurately ripped
  9   | (5/5) Accurately ripped
 10   | (5/5) Accurately ripped
 11   | (5/5) Accurately ripped
 12   | (5/5) Accurately ripped
[AccurateRip ID: 000ff65b-00955d8f-ad08480c] found.
Track   [  CRC   |   V2   ] Status
 01     [4f456a67|3e590718] (09+03/12) Accurately ripped
 02     [f079bd04|bb12e9e8] (09+03/12) Accurately ripped
 03     [72d0cc94|1125ef9a] (09+03/12) Accurately ripped
 04     [1e85ebc6|7a5e12d2] (09+03/12) Accurately ripped
 05     [05eaecaf|4f5c6b35] (09+03/12) Accurately ripped
 06     [c5a58f8c|10c53a0d] (09+03/12) Accurately ripped
 07     [334a8e1f|7efe2f01] (09+03/12) Accurately ripped
 08     [b07a89df|4ccede9b] (09+03/12) Accurately ripped
 09     [f48a8a88|01c65c41] (09+03/12) Accurately ripped
 10     [dd520537|d0a55829] (09+03/12) Accurately ripped
 11     [723d9e81|e9830e6a] (09+03/12) Accurately ripped
 12     [8b21c427|658f465f] (09+03/12) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   96,2 [07D56C06] [D236334F]           
 01   96,2 [22FA457E] [E8BD2508]   CRC32   
 02   90,7 [C6564A4E] [E12258B1]   CRC32   
 03   67,7 [87F2D289] [DF1176FA]   CRC32   
 04   87,2 [D21518EC] [0E7CC3BC]   CRC32   
 05   91,8 [5E97A1D2] [9BF975D0]   CRC32   
 06   90,8 [9E4ABAC0] [061F95E8]   CRC32   
 07   81,3 [2178157E] [B5E4E176]   CRC32   
 08   94,7 [D9139206] [C7C4CB66]   CRC32   
 09   82,9 [08C2AFC6] [E05B2F45]   CRC32   
 10   61,3 [7C672F27] [AD4A17BB]   CRC32   
 11   90,6 [EC97E162] [B3BCEBF9]   CRC32   
 12   95,7 [21390958] [096678BB]   CRC32


Not correctly ripped (+690 offset applied):

Code: [Select]
[CUETools log; Date: 23/07/2015 12:08:55; Version: 2.1.5]
Offset applied: 690
[CTDB TOCID: oIvFX8j3CpjAXxoaG80nqUK0sRI-] found.
        [ CTDBID ] Status
        [286d9cba] (5/5) Differs in 1175 samples @06:51:41-06:51:42
Track | CTDB Status
  1   | (5/5) Accurately ripped
  2   | (5/5) Accurately ripped
  3   | (5/5) Differs in 1175 samples @01:11:19-01:11:20
  4   | (5/5) Accurately ripped
  5   | (5/5) Accurately ripped
  6   | (5/5) Accurately ripped
  7   | (5/5) Accurately ripped
  8   | (5/5) Accurately ripped
  9   | (5/5) Accurately ripped
 10   | (5/5) Accurately ripped
 11   | (5/5) Accurately ripped
 12   | (5/5) Accurately ripped
[AccurateRip ID: 000ff65b-00955d8f-ad08480c] found.
Track   [  CRC   |   V2   ] Status
 01     [4f456a67|3e590718] (09+03/12) Accurately ripped
 02     [f079bd04|bb12e9e8] (09+03/12) Accurately ripped
 03     [9147d31b|3442a2e7] (00+00/12) No match
 04     [1e85ebc6|7a5e12d2] (09+03/12) Accurately ripped
 05     [05eaecaf|4f5c6b35] (09+03/12) Accurately ripped
 06     [c5a58f8c|10c53a0d] (09+03/12) Accurately ripped
 07     [334a8e1f|7efe2f01] (09+03/12) Accurately ripped
 08     [b07a89df|4ccede9b] (09+03/12) Accurately ripped
 09     [f48a8a88|01c65c41] (09+03/12) Accurately ripped
 10     [dd520537|d0a55829] (09+03/12) Accurately ripped
 11     [723d9e81|e9830e6a] (09+03/12) Accurately ripped
 12     [8b21c427|658f465f] (09+03/12) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   96,2 [0306A90C] [DE3DF86A]           
 01   96,2 [22FA457E] [E8BD2508] [2938E6DF]
 02   90,7 [C6564A4E] [E12258B1]  W/O NULL 
 03   67,7 [B64DBD16] [B2D0F2EE] [DF1176FA]
 04   87,2 [D21518EC] [0E7CC3BC]  W/O NULL 
 05   91,8 [5E97A1D2] [9BF975D0]  W/O NULL 
 06   90,8 [9E4ABAC0] [061F95E8]  W/O NULL 
 07   81,3 [2178157E] [B5E4E176]  W/O NULL 
 08   94,7 [D9139206] [C7C4CB66]  W/O NULL 
 09   82,9 [08C2AFC6] [E05B2F45]  W/O NULL 
 10   61,3 [7C672F27] [AD4A17BB]  W/O NULL 
 11   90,6 [EC97E162] [B3BCEBF9]  W/O NULL 
 12   95,7 [C2B0B206] [20BC2A99]  W/O NULL


Don't worry about track 03, please notice the last track (nr. 12) CRCs, instead:

Correct:  12  95,7 [21390958] [096678BB]  CRC32 
Not corect:  12  95,7 [C2B0B206] [20BC2A99]  W/O NULL

As you can see, the last track CRCs are different, while the other CRCs are the same (supposing track 03 was ripped correctly). Example:

Correct: 11   90,6 [EC97E162] [B3BCEBF9]   CRC32
Not correct: 11   90,6 [EC97E162] [B3BCEBF9]  W/O NULL

However, AccurateRip CRCs are the same for track 12:

Correct: 12    [8b21c427|658f465f] (09+03/12) Accurately ripped
Not correct: 12     [8b21c427|658f465f] (09+03/12) Accurately ripped

My question are:
1) Why does this happen? Or, why last track of different rips may have different CRC, but AccurateRip value is the same?
2) Why, in some other rips with different read offset, every track have the same CRC, including the last one, instead?
3) Why sometimes the only track with a different CRC, but again with identical AccurateRip value, is the first one of the album, and not the last one? It seems to depend on the applied offset anyway, with different results if it is positive or negative (positive offset = different CRC only last track, negative offset = different CRC only first track).

I hope my questions are clear.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2699 –
Quote from: Pidgeon on
My question are:
1) Why does this happen? Or, why last track of different rips may have different CRC, but AccurateRip value is the same?
2) Why, in some other rips with different read offset, every track have the same CRC, including the last one, instead?
3) Why sometimes the only track with a different CRC, but again with identical AccurateRip value, is the first one of the album, and not the last one? It seems to depend on the applied offset anyway, with different results if it is positive or negative (positive offset = different CRC only last track, negative offset = different CRC only first track).

See the Knowledgebase article on AccurateRip, Checksum calculation section. Calculation of the AccurateRip Checksum ignores almost 3000 samples from the beginning of the first track and the end of the last track to allow for offset correction.

You don't have to have null samples (zeroes) to have silence. Some albums have inaudible noise (samples with a CRC value but you cannot hear anything) at the beginning of the first track, between tracks, and/or the end of the last track. Other albums may pad these areas with null samples (zeroes).
For 2) the CRC wouldn't change (due to padding of zeroes by the ripping software) when using a different read offset if the samples in that area of the last track were already zeroes.
korth