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: After re-encoding some tracks with CUETools, "Bit-compare tracks" in foobar shows differences (Read 1296 times) previous topic - next topic - Topic derived from Binary Comparator ver...
0 Members and 1 Guest are viewing this topic.

After re-encoding some tracks with CUETools, "Bit-compare tracks" in foobar shows differences

Hello. I originally posted this in other forum, but since I did not receive an answer, I thought maybe I will find help here. My question is as follow:

After re-encoding some tracks with CUETools and comparing them with "Bit-compare tracks" in foobar, I always get this:
Differences found in all track pairs, all became identical after applying offset and truncating first/last samples.
Zero offset detected in 3 out of 3 non-identical track pairs.
Extra leading/trailing sections contained only null samples in 3 out of 3 non-identical track pairs.

Doing the same thing with Trader's Little Helper/dBpoweramp leads to:
All tracks decoded fine, no differences found.

These are all same exact tracks. What does CUETools do differently that bit compare reacts to it in such a way? Are these files being altered in some bad way as compared to the original ones? The offset value is set to 0. I know CUETools deletes metadata, so my FLAC files become smaller, removing unnecessary embedded album art and stuff. With Trader's Little Helper I get the same size, because none of the metadata is being touched. Perhaps this is the difference. Also, it mostly affects vinyl rips. None of it when re-encoding CD rips with log files

Any thoughts or explanation would be really appreciated

Re: After re-encoding some tracks with CUETools, "Bit-compare tracks" in foobar shows differences

Reply #1
You didn't provide any logs but one guess. The CUETools log would say 4608 samples were removed if that was what it did.
Truncated 4608 extra samples in some input files



Quote
Also, it mostly affects vinyl rips.
Second guess. CUETools will pad zeroes (null samples) up to the next CD sector boundary if a file does not end on a CD sector boundary. Again this would be noted in the CUETools log if this happened.
Padded some input files to a frame boundary
korth

Re: After re-encoding some tracks with CUETools, "Bit-compare tracks" in foobar shows differences

Reply #2
Wow, thank you! Sorry about not providing a log. Here is one of them:

[CUETools log; Date: 13/04/2023 18:36:17; Version: 2.2.3]
Truncated 4608 extra samples in some input files.
Padded some input files to a frame boundary.
[CTDB TOCID: IATboOjbaGOK4aVhQE4EJ6.rCOs-] disk not present in database.
[AccurateRip ID: 00055a46-00156f61-36076f04] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [7263BCCA] [CAC22CD5]          
 01  100.0 [7AFC8F9A] [812897D7]          
 02  100.0 [1BAC176C] [40EB6242]          
 03  100.0 [3F6AAD29] [EF398C4D]          
 04  100.0 [E65B59F6] [94B2F0D8]          

You are spot on!

In general, can I continue with this re-encoding practice? Because as I understand nothing essential is changed or lost from the original files and CUETools actually reduces the file size by removing embedded artwork, something I could not achieve with Trader's Little Helper or dBpoweramp

Re: After re-encoding some tracks with CUETools, "Bit-compare tracks" in foobar shows differences

Reply #3
Yes, but what Bogozo said also applies
⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄⌄

korth

Re: After re-encoding some tracks with CUETools, "Bit-compare tracks" in foobar shows differences

Reply #4
can I continue with this re-encoding practice?
If transition between tracks is gapless and not silent, this transition can be ruined by padding to frame boundaries.