Hydrogenaudio Forums > Different drives, produce completely different CRC's

Full Version: Different drives, produce completely different CRC's

Hydrogenaudio Forums > CD-R and Audio Hardware > CD Hardware/Software

Thaorius

Apr 15 2008, 11:20

Hi, my new Pioneer DVR-212 drive has just arrived. I installed it and decided to test it, The audio is extracted correctly, but, the tracks quality is considerably lower than the samsung's drive. And the track CRC, is enteryly different in both drives.

I compared the wav files. They all(but the first) say "6 missing samples at 00:00:00.000".

These are the ripping logs(samsing drive first):

CODE

Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 15. April 2008, 14:14

Unknown Artist / Unknown Title

Used drive  : TSSTcorpCD/DVDW SH-S182D   Adapter: 0  ID: 2

Read mode			   : Secure
Utilize accurate stream : Yes
Defeat audio cache	  : No
Make use of C2 pointers : No

Combined read/write offset correction	   : 0
Overread into Lead-In and Lead-Out		  : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations	   : No
Used interface							  : Native Win32 interface for Win NT & 2000
Gap handling								: Not detected, thus appended to previous track

Used output format : Internal WAV Routines
Sample format	  : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

	 Track |   Start  |  Length  | Start sector | End sector 
	---------------------------------------------------------
		1  |  0:00.00 |  1:40.69 |		 0	|	 7568   
		2  |  1:40.69 |  3:09.22 |	  7569	|	21765   
		3  |  4:50.16 |  3:29.23 |	 21766	|	37463   
		4  |  8:19.39 |  2:44.32 |	 37464	|	49795   
		5  | 11:03.71 |  4:49.68 |	 49796	|	71538   
		6  | 15:53.64 |  3:25.17 |	 71539	|	86930   
		7  | 19:19.06 |  3:53.10 |	 86931	|   104415   
		8  | 23:12.16 |  3:41.52 |	104416	|   121042   
		9  | 26:53.68 |  3:16.63 |	121043	|   135805   
	   10  | 30:10.56 |  3:16.56 |	135806	|   150561   
	   11  | 33:27.37 |  3:38.01 |	150562	|   166912   
	   12  | 37:05.38 |  6:25.38 |	166913	|   195825   


Track  1

	 Filename D:\MLib\Wave\01.wav

	 Peak level 90.4 %
	 Track quality 100.0 %
	 Copy CRC E4FFF923
	 Copy OK

Track  2

	 Filename D:\MLib\Wave\02.wav

	 Peak level 97.6 %
	 Track quality 99.9 %
	 Copy CRC B15E7D94
	 Copy OK

Track  3

	 Filename D:\MLib\Wave\03.wav

	 Peak level 97.7 %
	 Track quality 100.0 %
	 Copy CRC 638CC326
	 Copy OK

Track  4

	 Filename D:\MLib\Wave\04.wav

	 Peak level 97.6 %
	 Track quality 100.0 %
	 Copy CRC C371CE8D
	 Copy OK

Track  5

	 Filename D:\MLib\Wave\05.wav

	 Peak level 97.7 %
	 Track quality 99.9 %
	 Copy CRC 945F51E8
	 Copy OK

Track  6

	 Filename D:\MLib\Wave\06.wav

	 Peak level 97.7 %
	 Track quality 99.9 %
	 Copy CRC C677BB2F
	 Copy OK

Track  7

	 Filename D:\MLib\Wave\07.wav

	 Peak level 97.7 %
	 Track quality 99.9 %
	 Copy CRC E5B6CD0F
	 Copy OK

Track  8

	 Filename D:\MLib\Wave\08.wav

	 Peak level 97.7 %
	 Track quality 100.0 %
	 Copy CRC 78CAB440
	 Copy OK

Track  9

	 Filename D:\MLib\Wave\09.wav

	 Peak level 97.6 %
	 Track quality 100.0 %
	 Copy CRC 250FC298
	 Copy OK

Track 10

	 Filename D:\MLib\Wave\10.wav

	 Peak level 97.2 %
	 Track quality 100.0 %
	 Copy CRC 05D349DE
	 Copy OK

Track 11

	 Filename D:\MLib\Wave\11.wav

	 Peak level 97.7 %
	 Track quality 100.0 %
	 Copy CRC 3F552472
	 Copy OK

Track 12

	 Filename D:\MLib\Wave\12.wav

	 Peak level 97.7 %
	 Track quality 99.9 %
	 Copy CRC 97CC91E0
	 Copy OK

No errors occurred

End of status report

CODE

Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 15. April 2008, 13:55

Unknown Artist / Unknown Title

Used drive  : PIONEER DVD-RW  DVR-212D   Adapter: 1  ID: 2

Read mode			   : Secure
Utilize accurate stream : Yes
Defeat audio cache	  : Yes
Make use of C2 pointers : No

Read offset correction					  : 48
Overread into Lead-In and Lead-Out		  : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations	   : No
Used interface							  : Native Win32 interface for Win NT & 2000
Gap handling								: Not detected, thus appended to previous track

Used output format : Internal WAV Routines
Sample format	  : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

	 Track |   Start  |  Length  | Start sector | End sector 
	---------------------------------------------------------
		1  |  0:00.00 |  1:40.69 |		 0	|	 7568   
		2  |  1:40.69 |  3:09.22 |	  7569	|	21765   
		3  |  4:50.16 |  3:29.23 |	 21766	|	37463   
		4  |  8:19.39 |  2:44.32 |	 37464	|	49795   
		5  | 11:03.71 |  4:49.68 |	 49796	|	71538   
		6  | 15:53.64 |  3:25.17 |	 71539	|	86930   
		7  | 19:19.06 |  3:53.10 |	 86931	|   104415   
		8  | 23:12.16 |  3:41.52 |	104416	|   121042   
		9  | 26:53.68 |  3:16.63 |	121043	|   135805   
	   10  | 30:10.56 |  3:16.56 |	135806	|   150561   
	   11  | 33:27.37 |  3:38.01 |	150562	|   166912   
	   12  | 37:05.38 |  6:25.38 |	166913	|   195825   


Track  1

	 Filename D:\MLib\Wave\01.wav

	 Peak level 90.4 %
	 Track quality 99.8 %
	 Copy CRC A57BFDD6
	 Copy OK

Track  2

	 Filename D:\MLib\Wave\02.wav

	 Peak level 97.6 %
	 Track quality 100.0 %
	 Copy CRC 970649E5
	 Copy OK

Track  3

	 Filename D:\MLib\Wave\03.wav

	 Peak level 97.7 %
	 Track quality 100.0 %
	 Copy CRC 9810D596
	 Copy OK

Track  4

	 Filename D:\MLib\Wave\04.wav

	 Peak level 97.6 %
	 Track quality 100.0 %
	 Copy CRC 87FF47A8
	 Copy OK

Track  5

	 Filename D:\MLib\Wave\05.wav

	 Peak level 97.7 %
	 Track quality 99.9 %
	 Copy CRC 9410D70C
	 Copy OK

Track  6

	 Filename D:\MLib\Wave\06.wav

	 Peak level 97.7 %
	 Track quality 99.9 %
	 Copy CRC AA346AFC
	 Copy OK

Track  7

	 Filename D:\MLib\Wave\07.wav

	 Peak level 97.7 %
	 Track quality 100.0 %
	 Copy CRC D25E574E
	 Copy OK

Track  8

	 Filename D:\MLib\Wave\08.wav

	 Peak level 97.7 %
	 Track quality 100.0 %
	 Copy CRC DDE3982D
	 Copy OK

Track  9

	 Filename D:\MLib\Wave\09.wav

	 Peak level 97.6 %
	 Track quality 100.0 %
	 Copy CRC 4E0B2B47
	 Copy OK

Track 10

	 Filename D:\MLib\Wave\10.wav

	 Peak level 97.2 %
	 Track quality 100.0 %
	 Copy CRC E27148B3
	 Copy OK

Track 11

	 Filename D:\MLib\Wave\11.wav

	 Peak level 97.7 %
	 Track quality 100.0 %
	 Copy CRC 907624E2
	 Copy OK

Track 12

	 Filename D:\MLib\Wave\12.wav

	 Peak level 97.7 %
	 Track quality 99.9 %
	 Copy CRC F32C2F1A
	 Copy OK

No errors occurred

End of status report

How can this be happening?

PD: I'm testing with "Linkin Park - Minutes to Midnight", the disc has no scratches.

Thanks for your time

Moderation: Changed "code" to "codebox".

evereux

Apr 15 2008, 11:29

Configure your drive's read offset.

TuNk77

Apr 15 2008, 11:34

Edit, i was a bit wrong, but i ment to say the same as evereux

greynol

Apr 15 2008, 11:38

QUOTE(TuNk77 @ Apr 15 2008, 10:34)

You need to have the same setting for both drives, you have not set offset for the TSSTcorpCD/DVDW SH-S182D
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : No

--

PIONEER DVD-RW DVR-212D has read offset correction
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No.

As you can see, the settings are different.
Try the same setting for both drives and try again

Except for the part about the offsets, ignore what TuNk77 just said; it is not correct. Evereux has it right.

You should configure EAC to include null samples in CRC calculations, however.

greynol

Apr 15 2008, 12:06

I should have said this earlier, but it is clear that the read offset correction for your TSSTcorpCD/DVDW SH-S182D is +6.

Thaorius

Apr 15 2008, 12:10

QUOTE

Configure your drive's read offset.

That's what happens when I configure things late night :S. Well, I ripped 4 times the cd. The first 2 are in my first post, the other 2 times, I twisted EAC's settings and corrected the drive's offset, rips 1,3 & 4 are identical. So both drives seem to work properly.

Thanks for the help guys.

greynol

Apr 15 2008, 12:36

You should still configure EAC to use null samples in CRC calculations.

F9 -> Extraction Tab -> No use of null samples in CRC calculations: unticked.

Anyone who tells you this doesn't matter is not fully informed.

audioadam

Apr 16 2008, 14:23

QUOTE(greynol @ Apr 15 2008, 12:36)

I've always done this for my own personal backup reasons, (eg. So that I can later compare my digital audio to the CRC to prove it pristine with the least hassle. Even if it was checked though, I could still compare if if I didn't mind excluding null samples from the CRC calculation.) Is there another reason why you recommend it? Is it just to make the CRC more strict in the cases of Test & Copy, etc?

greynol

Apr 16 2008, 15:00

Yes, to make it more strict in cases of Test & Copy, especially in the case where you use different drives and one of them(*) happens to introduce a pair of null bytes resulting in channels being swapped and offset by a sample. Not including null samples for CRC calculations can hide this problem.

If the the setting is checked, you can check files that differ by an offset, but it will only work if those offset samples are null.

(*) This problem exists with some Hitachi-LG Data Storage drives. I've been told that these particular drives use a Panasonic chipset.

Tene

Apr 16 2008, 17:11

Maybe I'm missing something brain-dissolvingly obvious, but why don't you demux the audio data to a raw files and compare hashes of these files from both drives?

That would be quicker than sussing the effect of options on wav CRCs.

greynol

Apr 16 2008, 18:17

QUOTE(Tene @ Apr 16 2008, 16:11)

why don't you demux the audio data to a raw files and compare hashes of these files from both drives?

It doesn't sound like you're familiar with EAC.

1) EAC allows you to do a test rip and will display the CRC in a separate column in the GUI.

2) When you perform test & copy, both CRCs are displayed and will be included in the rip log.

Tene

Apr 16 2008, 19:33

QUOTE(greynol @ Apr 17 2008, 01:17)

QUOTE(Tene @ Apr 16 2008, 16:11)

why don't you demux the audio data to a raw files and compare hashes of these files from both drives?

No, I'm not. But what I'm saying is why doesn't the topic author use another tool to take hashes of raw files demuxed from the different wav files, in order to see whether it's simply a problem with the container rather than the audio data? If nothing else, it'll wipe one confouding possibility from the table.

Though I suppose I've done a stupid thing and speculated that the null samples are introduced at the container level. Which I guess in retrospect isn't the case. Perhaps a tool similar to dd could be used to remove the null byte, although since I have no idea whether EAC can do this automatically I shouldn't postulate further

Thaorius

Apr 16 2008, 19:43

QUOTE(Tene @ Apr 16 2008, 22:33)

QUOTE(greynol @ Apr 17 2008, 01:17)

QUOTE(Tene @ Apr 16 2008, 16:11)

why don't you demux the audio data to a raw files and compare hashes of these files from both drives?

Because logically, if I rip 2 times the same disc with eac, I should, in theory, get 2 exact wav files for each song. There for, I assume the containers are equal. And if they happen not to be, it's probably an error with the drives, because, eac should produce the same output given the same input, right?

By the way, I unchecked the option greynol said. Thanks for the advice guys.

greynol

Apr 16 2008, 20:13

QUOTE(Tene @ Apr 16 2008, 18:33)

But what I'm saying is why doesn't the topic author use another tool to take hashes of raw files demuxed from the different wav files, in order to see whether it's simply a problem with the container rather than the audio data?

He compared the files and his tool (EAC's wave compare function, if I'm not mistaken) found that there were 6 missing samples in the audio data. Even though the samples are really not missing (they're offset), this is the typical message that the tool gives for this situation.

QUOTE(Thaorius @ Apr 16 2008, 18:43)

eac should produce the same output given the same input, right?

So long as the drives are calibrated to one another with offset corrections and there aren't any discrepancies due to the inability to overread, EAC should produce identical files when ripping between different drives unless there were ripping errors that were inconsistent.

Tene

Apr 16 2008, 20:20

QUOTE(greynol @ Apr 17 2008, 03:13)

Okay, the information output seemed to imply they were CRCs of the resultant wav files, not of the audio data itself.

If they're simply offset, the raw files should be identical anyway, shouldn't they?

But anyway, this only serves curiosity, as the problem has been resolved.

Juan C.

Apr 16 2008, 22:00

I have a doubt after reading this. If I don't uncheck the option of "No use of null samples for CRC calculations" it does affect the audio quality or not?

Thaorius

Apr 16 2008, 22:13

QUOTE(Juan C. @ Apr 17 2008, 01:00)

I have a doubt after reading this. If I don't uncheck the option of "No use of null samples for CRC calculations" it does affect the audio quality or not?

No, it won't, it might produce different CRC's, given it won't take into account null samples. It might, has greynol said, cause some discrepancies on some drives.

greynol

Apr 16 2008, 23:49

QUOTE(Tene @ Apr 16 2008, 19:20)

If they're simply offset, the raw files should be identical anyway, shouldn't they?

No. It's as if the raw data in one file was 01234567, the raw data other one was 12345678. The data is not the same, so the CRC generated from this data will not be the same either. If you ignore the 0 and the 8, then yes, the rest is the same.

QUOTE(Thaorius @ Apr 16 2008, 21:13)

QUOTE(Juan C. @ Apr 17 2008, 01:00)

I have a doubt after reading this. If I don't uncheck the option of "No use of null samples for CRC calculations" it does affect the audio quality or not?

No, it won't, it might produce different CRC's, given it won't take into account null samples. It might, has greynol said, cause some discrepancies on some drives.

Not "might", changing the setting will produce different CRCs.

The chances that two different files give the same CRC goes down when you include samples with zero amplitude. IOW, the chances that an error goes undetected goes up when you base it on checksums that don't include samples with zero amplitude. This isn't just theoretical; instances of this happening have been reported to this forum as well as other places. There have also been situations reported where CRCs that included null samples revealed errors which may not have been discovered otherwise.

Will the calculation itself affect the audio in some way? No, of course not.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.