Open 45054 opened 7 years ago
Can you upload all four files and their sha1sums?
EAC even produces different checksums on different trys whereas whippers checksums stay the same on the same drive. I have therefore put 3 different EAC rips for the non HTOA drive, 2 whipper rips for every drive and 2 EAC rips for the HTOA drive into the archive: https://we.tl/GwxrbntHUi
The sha1 checksums are:
9471db80f222024ebd5bd4e6d48d1ab344c58161 20161119_ASUS_EAC_1.wav
b5cf8d5016c9f1b500715a373b7e98e59d04896b 20161119_ASUS_EAC_2.wav
f9379a36a39896ec4b1e3ad85edabcf4e8d7dbad 20161120_ASUS_EAC_3.wav
6a55ccec4d6027001e6eb8c5e08c48489b751c4a 20161120_ASUS_WHIPPER_1.wav
6a55ccec4d6027001e6eb8c5e08c48489b751c4a 20161120_ASUS_WHIPPER_2.wav
e45c18badc5e2b391a257beb2a2c903a92101cb3 20161120_PLEXTOR_EAC_1.wav
e45c18badc5e2b391a257beb2a2c903a92101cb3 20161120_PLEXTOR_EAC_2.wav
e45c18badc5e2b391a257beb2a2c903a92101cb3 20161120_PLEXTOR_WHIPPER_1.wav
e45c18badc5e2b391a257beb2a2c903a92101cb3 20161120_PLEXTOR_WHIPPER_2.wav
So the Plextor ones are identical and the whipper ones for ASUS are too.
@45054
Whipper rips done using the ASUS drive (not capable of extracting HTOA in an accurate way) look like this:
It seems that all the sectors which aren't readable are filled with zeros. The "zeroed" section is the one starting from offset 16057124
to 16085347
(this isn't the end of the file).
EAC rips, on the other hand, all have a different content (no whole zeroed section):
16027020
to 16409947
(the end of the file).16026548
to 16409947
).The conclusion (it really isn't a surprise) is that whipper can't override hardware limitations of the drive used for the ripping process, therefore accurate HTOA extraction can be expected only using capable drives.
OK. Thanks for investigating. Could the fact that whipper detects issues and fills the non readable parts with zeroes be reflected in the log? Otherwise the users might assume, that the HTOA was ripped correctly.
Thanks again.
OK. Thanks for investigating. Could the fact that whipper detects issues and fills the non readable parts with zeroes be reflected in the log? Otherwise the users might assume, that the HTOA was ripped correctly.
Unfortunately I don't know if cdparanoia (the component whipper uses to handle CD-DA extraction) has a consistent behavior (always fills with zero the HTOA) or if it also depends on the drive used. Maybe we can test ripping that HTOA just using cdparanoia in verbose mode in order to see how it comes up with zeroes and what status messages reports during the ripping phase...
@RecursiveForest Do you have an idea regarding a sane way to possibly handle this one?
@45054
Thanks for the log report.
I'm going to look at cdparanoia.py
to see if there's an easy way to handle this one.
@45054 I've checked and, as cdparanoia correctly reports read errors, it can be done. It's probably going to be fixed without additional work when #88 is completed.
Whipper is calculating other (matching) CRCs than EAC on drives that don't "officially" support HTOA. This could give the wrong impression of a correct rip.
ASUS DRW-24B1ST (non HTOA drive)
whipper log:
EAC log:
Plextor PX-W2410A (HTOA drive)
whipper log:
EAC log: