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): 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] [20976537] 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): 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:Track Extraction gaps Calculation method CRC32 3 Appended to previous EAC E43BBB08 4 Appended to previous EAC 7C89ECCC 3 Prepended to next EAC 20976537 4 Prepended to next EAC A18395BE 3 Appended to previous CUETools log E43BBB08 4 Appended to previous CUETools log 7C89ECCC 3 Prepended to next CUETools log E43BBB08 4 Prepended to next CUETools log 7C89ECCC 3 Appended to previous File3:Main 20976537 4 Appended to previous File3:PostGap + File4:Main A18395BE 3 Prepended to next File3:All 20976537 4 Prepended to next File4:All A18395BE 3 Appended to previous File3:All E43BBB08 4 Appended to previous File4:All 7C89ECCC 3 Prepended to next File3:All + File4:PreGap E43BBB08 4 Prepended to next File4:Main 7C89ECCC
Hopefully 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.