HTOA ripping on non HTOA capable drives

[45054]

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:

00:
Filename: Queens of the Stone Age/Queens of the Stone Age - 2002 - Songs for the Deaf/00 - Hidden Track One Audio.flac
Peak level: 0.853668
Extraction speed: 2.6 X
Extraction quality: 80.42 %
Test CRC: 70A8C7A7
Copy CRC: 70A8C7A7
Status: Copy OK

EAC log:

 Selected range   (Sectors 0-6976)

 Filename qotsaeacasus.wav

 Suspicious position 0:01:30 - 0:01:31

 Peak level 85.3 %
 Extraction speed 0.1 X
 Range quality 97.1 %
 Copy CRC 5F625FEB
 Copy finished

 There were errors

Plextor PX-W2410A (HTOA drive)

whipper log:

00:
Filename: Queens of the Stone Age/Queens of the Stone Age - 2002 - Songs for the Deaf/00 - Hidden Track One Audio.flac
Peak level: 0.853699 %
Extraction speed: 8.3 X
Track quality: 100.00 %
Test CRC: 8FF3CE7F
Copy CRC: 8FF3CE7F
Status: Copy OK

EAC log:

 Selected range   (Sectors 0-6976)

 Filename qotsaeacplextor.wav

 Peak level 85.3 %
 Extraction speed 8.2 X
 Range quality 100.0 %
 Copy CRC 8FF3CE7F
 Copy OK

 No errors occurred

[RecursiveForest]

Can you upload all four files and their sha1sums?

[45054]

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.

[JoeLametta]

@45054

1. As you've already stated ASUS_WHIPPER rips both match.
2. Each ASUS_EAC rip differs from the others.

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):

• Both ASUS_EAC_1 and ASUS_EAC_2 rips have the non matching section starting from offset 16027020 to 16409947 (the end of the file).
• ASUS EAC_3 is atypical because it has a non matching section starting earlier (from 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.

[45054]

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.

[JoeLametta]

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]

cdparanoia -v -O 6 -B 0 &> err.txt

[JoeLametta]

@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.

[JoeLametta]

@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.