How many sectors I remove from data track? Track02 has 0 gap. This is not in the guide.
1 2009-09-17 14:13:30 (edited by ghost 2009-10-03 17:08:02)
- ghost
- Dumper
- Offline
Dump this CD with CloneCD and check the gap in .cue. 2 seconds - 150 sectors, etc.
- provato
- Dumper
- Offline
ghost wrote:
How many sectors I remove from data track? Track02 has 0 gap. This is not in the guide.
Geia sou file mou, kalwshrthes sto redump.org!!! Loipon auto einai synhthes problhma gia ta ps1 paixnidia pou exoun MONO 2 tracks (1 audio kai 1 data).
Mias kai exeis LG drive dokimase th "method B" mexri na sou vgalei pregap 2.00 (shnythws vgazei 1.70, 1.92, 2.01 mexri na vgalei to swsto 
) Dhladh anoigo-kleineis to EAC kai kaneis detect gaps mexri na vgalei 2.00
***Auto kanto mono an sigoureuteis oti to pregap einai 2.00 (me th methodo pou anefere o Fireball)
Einai gnwsto auto to bug sthn EAC....
p.s: o,ti apories exeis mh distaseis na mou steileis mhnyma
4 2009-10-03 15:06:46 (edited by ghost 2009-10-03 15:15:14)
- ghost
- Dumper
- Offline
I hate to bring this up again but I have a new problem. I dumped with clonecd and I looked in the cue file and the pregap was 2 secs.
FILE "F22.img" BINARY
TRACK 1 MODE1/2352
INDEX 1 00:00:00
TRACK 2 AUDIO
INDEX 0 23:30:12
INDEX 1 23:32:12I dumped with isobuster the data and removed 352800 bytes. I dumped with eac the audio and here is the log:
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009
EAC extraction logfile from 3. October 2009, 11:34
Unknown Artist / Unknown Title
Used drive : PLEXTOR CD-R PX-W4012A Adapter: 1 ID: 1
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : Yes
Read offset correction : 76
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 Bit; Στερεοφωνικό
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 23:32.12 | 0 | 105911
2 | 23:32.12 | 5:30.71 | 105912 | 130732
Track 2
Filename C:\REDUMP\Νέος φάκελος\Track02.bin
Peak level 98.3 %
Track quality 100.0 %
Test CRC F8EE95C7
Copy CRC F8EE95C7
Copy OK
No errors occurred
End of status reportI mounted the image with this cue:
FILE "F-22 Air Dominance Fighter (Europe) (Track 01).bin" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
FILE "F-22 Air Dominance Fighter (Europe) (Track 02).bin" BINARY
TRACK 02 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:00I opened eac to check with both the cd and image mounted.
You can see that track01 ends at 23:32:12 although clonecd reported 23:30:12 but that's OK that's the eac bug.
Also look at the length of track02 is 5:30:71
Problem 1: Here you can see my image mounted and it shows the data track ending at 23:32:12 when it shouldn't because I removed 352800 bytes from it. It should end at 23:30:12 like clonecd reported.
Problem 2: Track02 length is 5:28:71 it chewed 2 secs from the audio!
This is a nightmare.
- Rocknroms
- Dumper
- Offline
You have to add 2 sec pregap manually as described in my faq.
psxt001z --gen 352800 pregap.bin
copy /b pregap.bin+track02.bin new_track02.bin
I know this is not yet in the main faq.
My patch requests thread
--------------------------------
--------------------------------
6 2009-10-04 07:22:15 (edited by ghost 2009-10-04 09:53:54)
- ghost
- Dumper
- Offline
Rocknroms it's not psx game its pc so I cant use that tool. However I made a progress. My LG drive in method B detected 2secs pregap and I dumped it 5:30:71 length.
BUT here is the thing. In my CD witch is perfect I never used it, there is a clicking sound in the first half second of the audio. I can hear this with my pc drives and my audio player. A manufacturing error?
In the sector view of isobuster i chose track02 and moving forward this time in sector 105915 I see this in the middle of nowhere, a desert of zeros:
what do you think? should I preserve this or remove it? is it garbage?
Then moving forward to sector 105935 in the last rows it appears that the song begins.
what do you think?
UPDATE: It appears that the galactic battlegorunds cd also has the same jitter in the beginning like F22 detectable unfortunatelly from the cd player also. Do I need to remove data from the start of track02 aswell?
- Rocknroms
- Dumper
- Offline
Rocknroms it's not psx game its pc so I cant use that tool. However I made a progress.
The command I wrote above has nothing to do with PSX, it simply creates a 2 sec 0x00 pregap, then you can merge it with no pregap track.
In the sector view of isobuster i chose track02 and moving forward this time in sector 105915 I see this in the middle of nowhere
Everything on CD has to be preserved.
My patch requests thread
--------------------------------
--------------------------------
- RetroGamer
- Dumper
- Offline
When the disc you want to dump has only 1 audio track, extract the audio track with EAC then run this .bat command in the directory where you have the extracted audio track and psxt001z.exe then delete the backup (.bak) file (if the gap is other than 2 seconds, edit this file according to the gap size). this is the same command that Rocknroms wrote but in a automated way.
By the way, we always assume that that gap was silence so we use 00's to fill the track 2 pre gap but if there is data in that pregap? it isn't better to extract the data track and the audio track and use the ReMove program to move the gap from the end of track 1 to the beggining of track 2? Maybe we should always use this program in discs with only one audio track.
"Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath a clear blue sky?"
- Rocknroms
- Dumper
- Offline
Track01 is data, track02 is audio ---> you cannot simply move those sectors.
If track02 pregap has some data it has to be preserved but in format mode of track02, so sectors with this bytes has to be scrambled. There's a tool around which help you to dump all disc in audio mode and then descramble data tracks (obviously every sector belonging to audio track will stay scrambled).
My patch requests thread
--------------------------------
--------------------------------
- themabus
- Dumper
- Offline
By the way, we always assume that that gap was silence so we use 00's to fill the track 2 pre gap but if there is data in that pregap? it isn't better to extract the data track and the audio track and use the ReMove program to move the gap from the end of track 1 to the beggining of track 2? Maybe we should always use this program in discs with only one audio track.
we would have to address garbage at the beginning of gap anyway
but you could use reMove to cut off this gap and it should inform how many samples different from 0x00 there were
if this value coincide with predicted offset (from Plextor, swapping or just different drive), it's pretty safe to do 'psxt001z --gen'
in opposite case gap's content can be verified to determine further action
what do you think? should I preserve this or remove it? is it garbage?
the garbage that is removed along with gap is nonexistent on actual media, it's an artefact of decoding,
always manifesting on data/audio boundary
you can tell buy descrambling it and it should form data sectors closest to audio data
- iR0b0t
- Administrator
- Offline
Guys, it doesn't contain any garbage in pregap, there is just some data in the 3rd sector of the track that "may" look like garbage, but it's not!
He has just to add 2 secs silent data to the 2nd track dumped in EAC and it's DONE!
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
- Rocknroms
- Dumper
- Offline
Nobody said it's garbage... by the way ghost made a lot of confusion.
If track01 is 105762 sec, those sectors (105915 and 105935) are part of track02 and are not in pregap so it can be dumped without any problem.
My patch requests thread
--------------------------------
--------------------------------
RetroGamer wrote:
it isn't better to extract the data track and the audio track and use the ReMove program to move the gap from the end of track 1 to the beggining of track 2? Maybe we should always use this program in discs with only one audio track.
It's possible, but the gap in the end of track 1 in 99% cases is incomplete. Basically, you should skip the (1st_track.size+combined_offset.size*4) and cut 150 sectors (150*2352=352800 bytes) after that. combined_offset.size*4 = garbage.size (in bytes). But any regular track 1 dump contains only (150*2352 - combined_offset.size*4) bytes of gap.
Imagine the 2MB CD, where 1st data track is 1MB and the 2nd audio track is 1MB, first 2 secs of 2nd audio track is pregap. The disc is burned with +100 offset and the drive has +30 read offset. CloneCD dump will contain: 1MB data track, then (100+30)*4 bytes of garbage, then 1048576-(100+30)*4 bytes of the 2nd audiotrack, total size of the dump = 2MB, the last (100+30)*4 bytes of the audio track will be missing. Track 1 dump from IsoBuster will contain: 1MB data track, then (100+30)*4 bytes of garbage, then 352800-(100+30)*4 bytes of the gap, the last (100+30)*4 bytes of the gap will be missing. (The example isn't very good, though, because 2097152 bytes can't be divided to 2352, so there can't be a 2MB disc, but I've wanted some rounded numbers).
There are 3 ways to cope with that.
1 - to write a proper dumping tool, if someone is interested, I'll help with technical docs, algorithms and testing (don't have enough time for coding).
2 - to extract the sector range in IsoBuster/CD Reader/CD tool/whatever (the next sector after the data track, length should be (352800+combined_offset.size*4)/2352 sectors (150,22 should be rounded to 151, 154,678 to 155, etc.), then you should cut the gap, skipping the garbage bytes: skip the combined_offset.size*4, the rest should contain the complete gap.
3 - to extract the bytes range from CloneCD dump - skip the (1st_track.size+combined_offset.size*4) and cut 150 sectors (150*2352=352800 bytes) after that.
14 2009-10-05 15:12:45 (edited by ghost 2009-10-05 15:14:18)
- ghost
- Dumper
- Offline
Then I will keep my dump as is and submit it soon. that data on the 3rd sector of track02 maybe it is a manufacturing error I can hear it on the actual cd. I thought maybe I could fix that.
- RetroGamer
- Dumper
- Offline
Now i understand... and after all, the bytes that we use to count the offset are in the begging of the gap (if we use ReMove), just one more thing to clear this up: if those bytes (the rows we use to calculate the offset) are removed from the data track and if they are not present in the first audio track then what's the deal? those bytes don't exist in the real disc and are generated by the drive?
Anyway thanks for the explanations, i had this idea bugging me since i started dumping discs with audio tracks lol
"Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath a clear blue sky?"
All the data is shifted - data and audio sectors. But any drive fixes the offset for data sectors automatically during the descrambling process.
For example, combined offset is +100, the drives reads the sector #0, then tries to descramble it. Data is shifted and first 100*4=400 bytes contain garbage (the last 400 bytes of the sector #-1, which is actually a 1st track pregap, which is written in sectors #-150 to #-1 and usually ignored by all the dumping tools), so the drive automatically reads 400 more bytes from the next sector, then descrambles it, then the drive reads the sector #1, first 100*4=400 bytes are garbage again, so it reads 400 more bytes from the next sector, etc. Afterall, the drive reads the last data sector, first 400 bytes are garbage again, so it reads 400 more bytes from the next sector (first audio sector, also 400 bytes of garbage in the beginning) to descramble the last data sector properly. Then, the drive reads the next sector (audio) "as is", then it reads the next sextor, the next, etc. But, if you remember, the first audio sector contains the last 400 shifted bytes, which belong to the previous data sector - so that's your "garbage".
The whole image is affected by the offset, but it's compensated for the data part and ignored for the audio. As a result, the last 400 bytes of the last data sector are written twice in the image - first, in descrambled form, as a part of the last data sector; second, in scrambled form, as a part of the first audio sector. Therefore, the last 400 bytes of the last audio track are totally missing, coping with that is the goal of Redump.org.