Maybe your drive doesn't read into lead-in/lead-out. Or maybe the pregap contains some data.
Try this. Dump track 02 using isobuster "Extract from-to" you'd need to calculate the exact sectors so it includes the pregap too. Then manually fix the offset. If your combined offset is +48, then remove 192 bytes from the beginning of the track, and add 192 bytes of 00s at the very end. See if that way it matches at least. I doubt it would serve as a verification since it's such a roundabout method, but at least you can see if you can match the track.
The answer is NO MATCH, anyway thank you again.
]]>I guess that's the answer because my GS-9082 is [3M] version. Maybe....
The data in DB is [1M] version.
Different Ring-Code.
]]>Maybe your drive doesn't read into lead-in/lead-out. Or maybe the pregap contains some data.
Try this. Dump track 02 using isobuster "Extract from-to" you'd need to calculate the exact sectors so it includes the pregap too. Then manually fix the offset. If your combined offset is +48, then remove 192 bytes from the beginning of the track, and add 192 bytes of 00s at the very end. See if that way it matches at least. I doubt it would serve as a verification since it's such a roundabout method, but at least you can see if you can match the track.
According the guide, the Track02 seems be converted by the PCM converter...
But I'll try your way, thanks.
]]>The Track01.bin(data) not match (and have one error), but Track02.bin is OK.
Someone can explain that?
I use the EAC099b5 with the same setting....
]]>Try this. Dump track 02 using isobuster "Extract from-to" you'd need to calculate the exact sectors so it includes the pregap too. Then manually fix the offset. If your combined offset is +48, then remove 192 bytes from the beginning of the track, and add 192 bytes of 00s at the very end. See if that way it matches at least. I doubt it would serve as a verification since it's such a roundabout method, but at least you can see if you can match the track.
]]>I read the guide carefully and do it step by step.
First, I pick a game with one data and one audio track, and it's not huge for saving error-testing time.
The Track01.bin is OK, but it always get the wrong Track02.bin against DB. (I've fixed it via ss_fixing)
I've read EAC bug topics about two track CD, and pick another game with multi-track.
Everything is OK and match DB, thus my setting seems fine.
So I post the [SS] World Advanced Daisenryaku: Sakusen File log for help, thanks.
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009
EAC extraction logfile from 29. November 2011, 4:39
Unknown Artist / Unknown Title
Used drive : PIONEER DVD-RW DVR-111 Adapter: 0 ID: 0
Read mode : Secure
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009
EAC extraction logfile from 29. November 2011, 4:45
Unknown Artist / Unknown Title
Used drive : PIONEER DVD-RW DVR-111 Adapter: 0 ID: 0
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 : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Appended to next track
Used output format : Microsoft PCM Converter
Sample format : 44.100 kHz, 16 ビット, ステレオ
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 24:07.55 | 0 | 108579
2 | 24:07.55 | 0:20.02 | 108580 | 110081
Track 2
Filename C:\new\TEST\Track02.bin
Peak level 97.0 %
Track quality 100.0 %
Test CRC FF5C1341
Copy CRC FF5C1341
Copy OK
No errors occurred
End of status reportAfter fix the 2 second gap problem, the hash of Track02.bin is...
MD5: 14f40ec2e532f9e835aab10a5c516423
SHA1: 456ddcb7b6fe4d3d8e5cd4559e67b7315837395e
CRC32: cc93f8cfThe Track 02 start on sector 108580, and scramble data begin from sector 108430 and 48 samples long.
I've dump it 6 times, and thanks everyone for reading my post.
]]>