CRC32 mismatches in CUETools log when gaps prepended to next track 2018-09-29 04:46:10 I am using Exact Audio Copy v1.3 to rip albums with gaps prepended to the following track ("Appended to next track" setting). Any write operation I try to perform with EAC fails with my DVD writer, so I am using CUETools v2.1.6 (though I see the same behavior described below with v2.1.7 as well) to modify the .wav files so as to negate my writer's write offset before burning them to disc with ImgBurn. This works fine; ripping a burned disc yields .wav files identical to those ripped from the original pressed disc. My rips are also confirmed by AccurateRip with high confidence, so there are no concerns there.What I did find curious is that when I run an operation in CUETools it performs a verification of the CRC32 values from the EAC log, and the values CUETools calculates don't always match what EAC calculated. Sometimes it is just a few tracks that don't match, sometimes it is most tracks. Here's an example from one album:CUETools log EAC-style info (gaps prepended):Code: [Select]Track Peak [ CRC32 ] [W/O NULL] [ LOG ] -- 100.0 [788A15CF] [BA31310E] 01 100.0 [B0A55C46] [61CE6A93] CRC32 02 99.7 [F12B0F4C] [3B860B61] CRC32 03 100.0 [E43BBB08] [4F8E8196]  04 100.0 [7C89ECCC] [EE3D7F4C] [A18395BE] 05 99.3 [BBDA580F] [33E3E970] CRC32 06 99.2 [F7FCFC87] [89BF5A5F] CRC32 07 99.3 [D68D9665] [7A3BFD7F] CRC32 08 100.0 [9B34AC01] [0AE1A531] CRC32 09 100.0 [E577BA2B] [EC3CA8B6] [24EA7D15] 10 100.0 [E20851E6] [5BFA3319] [66A78D20] 11 100.0 [892F3A30] [8448FD67] CRC32 12 98.8 [B18E55A0] [FF7FBC51] CRC32 13 99.0 [2D53534F] [5693CE1E] CRC32 I was going to post asking, for the sake of curiosity, what would cause this result and what it means, but after much searching and not finding anything I finally got the idea to see what happens if I rip with gaps appended. Here's the same album ripped that way:CUETools log EAC-style info (gaps appended):Code: [Select]Track Peak [ CRC32 ] [W/O NULL] [ LOG ] -- 100.0 [788A15CF] [BA31310E] 01 100.0 [B0A55C46] [61CE6A93] CRC32 02 99.7 [F12B0F4C] [3B860B61] CRC32 03 100.0 [E43BBB08] [4F8E8196] CRC32 04 100.0 [7C89ECCC] [EE3D7F4C] CRC32 05 99.3 [BBDA580F] [33E3E970] CRC32 06 99.2 [F7FCFC87] [89BF5A5F] CRC32 07 99.3 [D68D9665] [7A3BFD7F] CRC32 08 100.0 [9B34AC01] [0AE1A531] CRC32 09 100.0 [E577BA2B] [EC3CA8B6] CRC32 10 100.0 [E20851E6] [5BFA3319] CRC32 11 100.0 [892F3A30] [8448FD67] CRC32 12 98.8 [B18E55A0] [FF7FBC51] CRC32 13 99.0 [2D53534F] [5693CE1E] CRC32 As you can see, the CRC32 and W/O NULL columns are identical to the other log, but now there are no mismatches in the LOG column. If needed I can post the CUE sheet, but, in short, there are only two gaps in the entire album: between tracks 3/4 and between 9/10, which happens to correspond to the four tracks with CRC32 mismatches in the gaps-prepended log.To try to figure out how CUETools is arriving at those CRC32 values, I wrote my own code to calculate the CRC32 of various permutations of all or some of file 3 concatenated with all or some of file 4, and compared those to the values calculated by EAC and CUETools: TrackExtraction gapsCalculation methodCRC32 3Appended to previousEACE43BBB08 4Appended to previousEAC7C89ECCC 3Prepended to nextEAC20976537 4Prepended to nextEACA18395BE 3Appended to previousCUETools logE43BBB08 4Appended to previousCUETools log7C89ECCC 3Prepended to nextCUETools logE43BBB08 4Prepended to nextCUETools log7C89ECCC 3Appended to previousFile3:Main20976537 4Appended to previousFile3:PostGap + File4:MainA18395BE 3Prepended to nextFile3:All20976537 4Prepended to nextFile4:AllA18395BE 3Appended to previousFile3:AllE43BBB08 4Appended to previousFile4:All7C89ECCC 3Prepended to nextFile3:All + File4:PreGapE43BBB08 4Prepended to nextFile4:Main7C89ECCCHopefully that's not information overload, but the important takeaways are:CUETools calculates the same CRC32 values regardless of the gap handling used when extracting the tracks (rows 5-8), and...When CUETools calculates the CRC32 values for tracks with gaps prepended (rows 7-8) it yields the same results as when tracks with gaps prepended are reassembled with gaps appended (last two rows)Therefore, it appears that, when processing EAC logs, CUETools always calculates CRC32 values with gaps appended, regardless of the gap handling used by EAC during ripping. I also took a cursory look through the source code and do not see anywhere that the Gap handling line from the beginning of the EAC log is being read in so CUETools can use the same handling. Of course, it is to be expected that a stored hash will not match a verification of that hash if the input data is not arranged in the same way.I am inclined to suggest that this is a bug, but I suppose that depends on what the purpose is of the CRC32 calculations performed by CUETools. If, as I assume, they are meant to verify that the .wav files have remained unchanged since they were ripped, then CUETools would need to ensure it uses the same gap handling as EAC did. If, however, it's intentional that CUETools always calculates CRC32 values with gaps appended regardless of the original gap handling (perhaps to allow for consistent, gap handling-agnostic comparisons of multiple rips of the same disc? just spitballing ideas...), then I think it would be helpful if the wiki were updated to make that technical detail clear. Last Edit: 2018-09-29 04:50:29 by BACON.