You are not logged in. Please login or register.
Redump Forum → History for fixes → [DONE] [PCE] Road Spirits (J)
Did you guys (themabus) use subchannel correction on data track pregaps?
I got 2.74 instead of 3.00 (db) for both data tracks
SUBs
px-760a.clonecd.sub - http://www.mediafire.com/?h1nnytwnmmn
px-760a.perfectrip.sub - http://www.mediafire.com/?wmyzznj4zmoThemabus was the dumper for the most of PCE CD titles, he had a very bright idea to round all the gaps, so all the dumps can be called 'bad' now. http://forum.redump.org/topic/2559/a-br … ry-on-pce/ -- details.
thank you F1ReB4LL
hi iR0b0t
back when we started adding PCE to redump.org,
we decided not to diversify PCE dumps whenever it's apparent that same track layout was used,
and those gap differences (2:74 vs 3:00 or alike) are present only in subcode
since then for some time i had my doubts about this decision myself,
until eventually it became clear that this action is not different from offset adjustments -
corrections we'd apply to mastering artefact, in order keep meaningless variations i.e. clones down
Themabus' drives give different subs with different gaps for the same CDs, someone should examine it again.
lol, it is a little bit to much to read for me now, I just want to dump 2-3 games 
What should I do now, I can post subs when needed (?)
Try to dump them on as much drives as possible. If you get the same gaps on different drives -- you can add them again (no need in fixing the current entries, PM me and I'll hide them). Subs will be welcome.
Themabus' drives give different subs with different gaps for the same CDs, someone should examine it again.
to discover what?
from the topic you gave link to it should be clear enought,
that some of those CDs return differents gap sizes from those submitted to db
does it mean anything?
no
i don't know what is the reason of your fascination with this issue, F1ReB4LL
when you think about it, it's not different from any other alike
there are numerous recurrent patterns of how fields in subchannel Q can differ from expected values
(including: Mode2 sections (those empty ones), P different from Q, track boundaries from Q exceeding ones from TOC, invalid MSF sequences)
most often they'd occur in those older CDs like PCE, SCD, etc.
and most of them can affect reported sizes for the gaps
what you'd do usually in such cases: you'll adjust gaps to expected - most common values for the system
what is the common gap values for PCE tracks?
3:00, 2:00, 0:00
now when you look at those CDs with supposedly 2:74 gaps,
most of the time you'll see that they're different from 3:00 ones only by subcode
it's easy to tell by Track 01: when you separate 2:74 gap, thers blank audio sector left at the end of it
and when you move this blank sector to 2nd track, 1st will give common CRC value
what does it mean?
that some CDs were mastered with Track 01 different from the others by 1 sector
and in those cases mastering crew would careffuly select to generate 2:74 gaps instead of 3:00?
no
it means that some mastering machines mess up subcode, just the same as with all the other subcode artefacts mentioned above
only this time it's more complex - since it's not one or two Q fields but most of them
now when you go for reported gap values all you get is theoretically countless diversity of records
for what reason really F1ReB4LL?
how is this different from all other subcode artefacts, when you'd take an subjective decision to adjust gaps
(i recall you being pretty passionate yourself about correction of Mode2 sections)
how is this different from offset cancelation?
what you'd do usually in such cases: you'll adjust gaps to expected - most common values for the system
Never. We should dump everything 1:1 without rounding/fixing anything. And give me any examples of our 'gaps adjusting', please (except your dumps).
what does it mean?
that some CDs were mastered with Track 01 different from the others by 1 sector
and in those cases mastering crew would careffuly select to generate 2:74 gaps instead of 3:00?
So what? We dump the actual CDs, not masters or something, it's not about imagine the things - it's about getting the actual contents.
here is the subs for "Road Spirits" http://www.mediafire.com/?h1nnytwnmmn
EAC detects 00:01 pregap for Track07, but PR detects no pregap here, please check the sub entry for this track as well, thanks
Never. We should dump everything 1:1 without rounding/fixing anything. And give me any examples of our 'gaps adjusting', please (except your dumps).
I think Dreamcast data pregaps of last track in high density area are also 'incorrect'.. IIRC themabus once wrote that subchannels indicate 3 sec gaps?.. I don't remember checking them myself.. I just assumed back then that the first sector with sync/header was the first track sector (else a track would contain both types of data, which is pretty pointless).
By his logic, we should round all the Saturn and Mega CD 02:00-01:74 gaps to 02:00, and all the 01:74 and 02:02 gaps in serpentine cases to 02:00 as well. WTF?
here is the subs for "Road Spirits" http://www.mediafire.com/?h1nnytwnmmn
EAC detects 00:01 pregap for Track07, but PR detects no pregap here, please check the sub entry for this track as well, thanks
It's fine, false 00:01 report is due to the EAN sector, but I don't like the 3rd track pregap -- there are 5 'copied' sectors (AMSF 03:01:00 to 03:01:04 followed by the same 5 sectors), 00:02:05 instead of 00:02:00 as a result. What's about different drives? I'd also like to see PR subs.
perfectrip subs, from same drive like previews one (px-760a) http://www.mediafire.com/?wmyzznj4zmo
maybe more later... when needed
As soon as I will have finished some PC/GC I will take my hands on my PCE. I should confirm only Ys IV, Valis IV and Forgotten Words.
In my opinion we have to take contact with someone who mastered Sega /PCE stuff *** to see if it's possible to know something more about multi alternates, gaps and so on. If we can have a confirmation that some discs (also according to ring codes) had been mastered bad, we can fix the gaps. By the way I don't know if this could be ever possible.
*** Some of the Doujin CDs I dumped in the last days have similar ring codes to Sega / PCE (they have the same matrix structure), so they are still around.
perfectrip subs, from same drive like previews one (px-760a) http://www.mediafire.com/?wmyzznj4zmo
maybe more later... when needed
Similar 5-sector doubles on AMSF 00:47:70-00:47:74 and 45:19:18-45:19:23, which results in 00:03:04 instead of 00:02:74 for Track02 and Track21. Same for the most of Themabus' subs, btw (I've examined them before).
Never. We should dump everything 1:1 without rounding/fixing anything. And give me any examples of our 'gaps adjusting', please (except your dumps).
you're asking for impossible, F1ReB4LL
you know better than me that such information isn't kept, only what's submitted in form
but instead i can provide you a link where you're going about correction of EAN sections
(i'd refer to them as Mode2 as by ECMA-130 definition)
http://forum.redump.org/topic/3152/ss-s … ed-041208/
It's fine, false 00:01 report is due to the EAN sector
here you go again
let me remind you, what you said less than an hour ago prior to this statement:
"We should dump everything 1:1 without rounding/fixing anything"
but I don't like the 3rd track pregap -- there are 5 'copied' sectors (AMSF 03:01:00 to 03:01:04 followed by the same 5 sectors), 00:02:05 instead of 00:02:00 as a result. What's about different drives? I'd also like to see PR subs.
yes, let's choose to believe results we find most appealing...
So what? We dump the actual CDs, not masters or something, it's not about imagine the things - it's about getting the actual contents.
sadly this doesn't hold as an argument
but never the less is an interesting statement for two reasons:
1) it demonstrates how incomplete is your concept of mastering
2) it's another contradiction between your statements
* CDs we extract data from are pressed from masters and should be exact copies of those
* 'dumping masters' is what you actually propose
let me explain this more thoroughly:
back then in late 80s early 90s data for CD masters was submitted on magnetic tapes
there weren't subcode or gaps there, only actual data for tracks and possibly layout info
so subcode and gaps would be generated when master is created
there could be one master or several
so since being recreated anew this info could actually differ for each master
each CDs relation to it's master is pressed in ring code
now clever way to extract this information would be to cancel all those differences from different masters
that's what we do with offset
that's what you suggest to do with EAN
yet in this analogy to offset you are proposing now that we should backup those differences of each particular master
i.e. not correct CD offset
i find it strange how you seem to understand one case but completely fail to see resemblance with the other one
let me also remind you that this decision to correct gaps wasn't entirely mine
it was largely mine indeed as gigadeath and me were about only people dumping those CDs then
but we discussed it and Dremora agreed to it
http://forum.redump.org/topic/2174/woul … se/page/2/
now what you're doing isn't nice at all, F1ReB4LL
all due respect, but i don't believe your opinion is most important
if you feel like it, we should at least discuss it among staff, not here
and maybe cast an vote
yet so far you succeeded very well in denying reason
and provided no more than some demagogic shouts
but instead i can provide you a link where you're going about correction of EAN sections
(i'd refer to them as Mode2 as by ECMA-130 definition)
http://forum.redump.org/topic/3152/ss-s … ed-041208/It's fine, false 00:01 report is due to the EAN sector
here you go again
let me remind you, what you said less than an hour ago:
"We should dump everything 1:1 without rounding/fixing anything"
It's not about fixing anything, it's about one of the core EAC bugs, which results in wrong gaps. When EAC meets the EAN sector between 2 tracks, it assumes this sector belongs to the next track, while in reality it belongs to the previous one. You may look into IEC 60908 (which actually allows both variants, but not strictly the only one, like EAC does), if you have any doubts about this.
now clever way to extract this information would be to cancel all those differences from different masters
that's what we do with offset
that's what you suggest to do with EAN
I've already explained you about EAN, there's nothing about 'fixing' anything. Fixing offset is a different story. We don't dump ALL the sectors from the CD (LeadIn -> 1st data track pregap (sectors #-150 to -1) -> Data (sectors #0 to [LeadOut]-1) -> LeadOut -> Ring (only for Saturn)). Regular dumps contain only the Data part, we also dump only the Data part, but to make a correct dump, we should read exactly this range - from the first byte of the sector #0 to the last byte of the pre-leadout sector, fixing both read and write offsets gives us exactly this, so it's not about any masters or something, it's just the only way to read the proper range.
I agree, that it would be nice to get the original files, but you can't recover them, you can only assume the variant. But as you know, when you assume, you're assing both u and me, so I hope we won't add imaginary things and call them 'proper' dumps. Afterall, Redump is a Disc Preservation Project, not Masters Restoring Project, so we should just dump everything as close to the original CDs, as possible.
when you assume, you're assing both u and me
rofl, is that from a movie or something? 
didn't know russians have a sense of humour
Arguing with mamedevs helps to improve your English a lot 
You may look into IEC 60908 (which actually allows both variants, but not strictly the only one, like EAC does), if you have any doubts about this.
'which actually allows both variants'
let's keep this in mind
it's about one of the core EAC bugs, which results in wrong gaps. When EAC meets the EAN sector between 2 tracks, it assumes this sector belongs to the next track, while in reality it belongs to the previous one.
'it's about one of the core EAC bugs'
perhaps 'bug' isn't quite fitting description for interpretation of something,
that's left open for interpretations,
don't you think, F1ReB4LL?
'EAC assumes ... while in reality ...'
so in situation where results can be interpretet EAC assumes, but not you F1ReB4LL?
so how would you know?
perhaps by common gap values for given system?
'results in wrong gaps'
and how exactly would you tell right from wrong, F1ReB4LL?
by rereading subcode N times until your expected result (common value for given system)
is returned, like you suggest in post above?
creativity isn't something you're lacking, F1ReB4LL
i must applaud for that
I've already explained you about EAN, there's nothing about 'fixing' anything.
are you sure it isn't 'fixing' F1ReB4LL?
because some combination of Drive X and Software Y return those results after N tries?
could you suggest a better fitting word then, please?
Fixing offset is a different story. We don't dump ALL the sectors from the CD (LeadIn -> 1st data track pregap (sectors #-150 to -1) -> Data (sectors #0 to [LeadOut]-1) -> LeadOut -> Ring (only for Saturn)).
indeed we don't, let's keep that in mind for a minute
I agree, that it would be nice to get the original files, but you can't recover them, you can only assume the variant.
i don't agree with this statemen, though.
if you think inclusion of Lead-In/ Lead-Out,
protected areas such as Sega/DC rings and what not for each CD would be a nice,
please think some more about it F1ReB4LL
strangely enough you forgot to mention another important aspect of offset correction
most important perhaps
are those few bytes we'd recover really that meaningful? - it's only a fraction of second
(less than 1/75 most of the time)
and after all we're not including a lot more bytes from other areas, like you mention above
so, maybe what really matters about offset correction
is the fact that it eliminates meaningless clones
and makes comparation of data far more convenient in following cases:
* same CDs from different masters
(there are such cases in db when one record has several offsets)
* different editions for same game
* different regions for same game
* maybe even different systems for same game
it's strange you'd forget this small detail, F1ReB4LL
your hate posts towards TOSEC @UG are full of those references
now where does offset come from?
from dissimilarity of frames with subcode bytes
it is an attribute of mastering equipment
back then complex machines, now CD recorders
so it's easy to verify this nowadays - you'd need to records mixed CD on different burners
and this offset would differ, independent of software
are you not correcting offset?
you are.
basing your actions on assumption that you know correct value
and data returned from CD as it is needs this correction
are you correcting gaps?
you are.
the same way
Never. We should dump everything 1:1 without rounding/fixing anything. And give me any examples of our 'gaps adjusting', please (except your dumps).
um yeah...
so what are gaps?
attribute of mastering equipment
and it's not only subcode that matters, you see
but also sector content
on this level gaps would consist of empty sectors as defined in ISO, etc.
now for PCE ther's an common Track 01 with similar CRCs for most of the CDs
this track would usually be followed with gap consisting from:
75 empty audio sectors and 150 empty mode 1 sectors
(last sector of Track 01, prior to gap, holds meaningful audio samples)
in cases when such gaps are detected as 2:74,
ther's still exactly same Track 01 data followed by same amount of empty sectors
only difference is in subcode
ther's also some cases of those gaps being market as 2:00 in subcode
still sector content is exactly the same
also if you'd care to read this topic:
http://forum.redump.org/topic/2559/a-br … ry-on-pce/
ther's an curious case for CD with similar ring pattern as for those affected with this problem
when 2:74 gap would be reported between two adjacent audio tracks (it's usually 0:00)
examining it on sector level reveals inserted 225 sectors of silence (not 224)
is this not enough to base correction upon?
when you're correcting EAN, F1ReB4LL, you have far less evidence of mastering problems
now what are the actual differences between two proposed schemes?
* in one case we get larger variety of records, possibly even clones (a la TOSEC)
* in the other we don't (redump.org always was about applying certain corrections,
please don't deny it
for reference check psxt001z --fix option
or guides describing extraction of data from protected media,
where you'd replace sector content with generic $55 pattern
with offset correction and certain interpretations of subcode you are familiar already)
in this case, with this correction applied, no information is lost
would tracks from both sets be recombined into one stream again, they'd match
so why are you so anxious to diversify db, F1ReB4LL?
I think themabus is winning this argument.. we're not preserving subchannels and as a result a lot of dump info and data has been lost already while preserving.. we're adding the effect of these subchannel 'errors' into the main channel data, but there's no real point in doing that.. it doesn't improve the dump.. the only way to properly deal with it and really get 100% dumps is to merge all tracks (after all, we're not sure which gaps are intended, even if we have the subchannels) and accurately preserve the subchannels, which we're not doing..
We're already adjusting the dump data to remove offset mastering effects, so why shouldn't we do the same for gaps and only record any subchannel discrepancies instead of applying them to the dump data? This means we should store subchannel 'differences' in a layout similar to the libcrypt sectors and go with the logical 'intended' gaps (so no more tracks with weird gaps because of subchannel mastering 'errors'). Removing any mastering effects from the dump and documenting them separately is the way to go imho. The most important reason has already been mentioned: by documenting these mastering differences instead of applying them to the main channel data, we remove any unnecessary differences and have the main channel data in its 'intended' form (without failing to preserve anything or really altering the dump)...
Not going technical like themabus did (even if I side with him), but simply in good ol' empirical way, I often got completely different result with my 3 drives, using EAC or PerfectRip (for PCE, often=always).
I mean things like:
drive X returns 2.74 gap with EAC
BUT
drive X returns 3.00 with PerfectRip
BUT
drive Y returns 3.01 with EAC (WTF?)
BUT
drive Y returns 2.74 with PerfectRip (WTF?x2)
BUT
drive Z returns even more random numbers with either software
Another example for PCE would be track 3 pregap when track 2 is data, you could get 2.00, 1.74, 0.00 depending on the drive and the software.
We round things up because THE SOFTWARES THEMSELVES ROUND THE THINGS UP, wheter they like/dislike the drives, whether they like/dislike the subs, wheter they like/dislike that particular disc.
The reading routines just act wildy depending on too many factors. Just try dumping Valis IV without some kind of post-dump rounding, and see if you ever gonna get consistent results. Good luck at that (I tried). I mean like 30 different gaps in a single disc that give you different results with every setup you dump with.
If you look at the actual gap sectors, the gaps are always 2.00, 3.00, for PCE and MCD alike. Always. And, at least for PCE, no rounding could mean no verifications at all, unless the verifier gets the exact same drive and uses the exact same software.
'results in wrong gaps'
and how exactly would you tell right from wrong, F1ReB4LL?
by rereading subcode N times until your expected result (common value for given system)
is returned, like you suggest in post above?
creativity isn't something you're lacking, F1ReB4LL
i must applaud for that
I've already explained you about EAN, there's nothing about 'fixing' anything.
are you sure it isn't 'fixing' F1ReB4LL?
because some combination of Drive X and Software Y return those results after N tries?
could you suggest a better fitting word then, please?
is this not enough to base correction upon?
when you're correcting EAN, F1ReB4LL, you have far less evidence of mastering problems
You know, what your problem is? You don't want to read my explanations, you just ignore everything and repeat the same things every time, like a parrot.
When EAC meets the EAN sector between 2 tracks, it assumes this sector belongs to the next track, while in reality it belongs to the previous one.
EAN sector usually replaces one of the real sectors. Sometimes, it may replace the very last sector of the track or the very first one:
01 09 01 02 20 10 00 15 57 12 49 CC
01 09 01 02 20 11 00 15 57 13 F3 BC
02 00 00 00 00 00 00 00 00 14 73 C0
01 10 00 00 01 73 00 15 57 15 08 9F
01 10 00 00 01 72 00 15 57 16 92 AD
When EAC faces this situation, it always assumes this EAN sector belongs to the next track (Track#10 here), while it can belong to the previous track (#09), too (this is described in the IEC 60908). It's one of the EAC bugs and it's not drive-dependant, it works like this even with virtual drives, so it's about decoding the subs manually, not 'looking for the correct drive' and not about 'fixing the gaps'. I hope you won't touch this thing anymore.
are you not correcting offset?
you are.
basing your actions on assumption that you know correct value
and data returned from CD as it is needs this correctionare you correcting gaps?
you are.
the same way
We don't correct any gaps, stop imagine things. We can only refuse results from one of the tools, when it's known it has a bug. But we never fix any gaps, just because we don't like them and all the other CDs on this system have different beautiful rounded gaps.
As for the offset, I repeat, you can't dump the CD without fixing it, because the post-data audiotrack will have the garbage, you can either fix the offset or cut the pregap out to mask it (like CDRWin does). So it's not about assuming the values, it's just about dumping the _proper_ range.
if you think inclusion of Lead-In/ Lead-Out,
protected areas such as Sega/DC rings and what not for each CD would be a nice,
please think some more about it F1ReB4LL
I'm afraid it's very hard to find a drive, which can read ALL the sectors. Even your beloved Plextors fail at reading some of the -150 to -1 sectors (but they do read pre -150 sectors with the LeadIn area). And in my opinion it would be better to dump everything in scrambled form, like it's written on the real CDs. Descrambled datatracks remind me those decrypted NeoGeo roms, which don't really contain the actual media content.
strangely enough you forgot to mention another important aspect of offset correction
most important perhaps
are those few bytes we'd recover really that meaningful? - it's only a fraction of second
(less than 1/75 most of the time)
and after all we're not including a lot more bytes from other areas, like you mention above
so, maybe what really matters about offset correction
is the fact that it eliminates meaningless clones
and makes comparation of data far more convenient in following cases:
* same CDs from different masters
(there are such cases in db when one record has several offsets)
* different editions for same game
* different regions for same game
* maybe even different systems for same game
I repeat, the most important thing is to read the whole 'Data' range from the first byte upto the last, without any cuts, TOSEC fails at that point. Eliminating the clones is a nice bonus, but it's not about targeting at eliminating them. OK, a few examples:
1) http://redump.org/disc/2597/ -- by your logic we should round all the 00:01:74 gaps here to 00:02:00.
2) http://redump.org/disc/5194/ -- by your logic we should round all the 00:02:02 gaps here to 00:02:00
3) http://redump.org/disc/5263/ and http://redump.org/disc/3661/ -- same CD, but the offset is 0, audiotracks are the same, but shifted, by your logic we should find the offset _somehow_ and merge the entries.
4) http://redump.org/disc/3717/ -- this CD contains a standard 10-secs warning, but in this particular case it was shifted during the mastering and misses some samples at the end. By your logic we should replace it with the known 10-secs warning instead of the one written on the real CD, because it was corrupted during the mastering.
5) http://redump.org/disc/3376/ and http://redump.org/disc/5266/ -- audiotracks have a 1-sectors length difference, we should also fix it, right?
etc, etc, etc. I'm afraid this won't be about the proper dumping anymore, just about the assuming (actually, assing everyone).
for reference check psxt001z --fix option
or guides describing extraction of data from protected media,
where you'd replace sector content with generic $55 pattern
with offset correction and certain interpretations of subcode you are familiar already)
in this case, with this correction applied, no information is lost
would tracks from both sets be recombined into one stream again, they'd match
Fixing the very last pre-audio Mode2 track is necessary, it's not about mastering issues, it's about most of the drives read this sector incorrectly (and differently every time). Some of the drives do read this sector properly, though, there's no need in psxt001z --fix for them. So you've chosen the wrong example again.
As for the replacing sectors with $55 pattern - guess, this is about PC discs, dunno, I don't like the PC section at all, it's a pile of trash in its current state.
I think themabus is winning this argument.. we're not preserving subchannels and as a result a lot of dump info and data has been lost already while preserving.. we're adding the effect of these subchannel 'errors' into the main channel data, but there's no real point in doing that.. it doesn't improve the dump.. the only way to properly deal with it and really get 100% dumps is to merge all tracks (after all, we're not sure which gaps are intended, even if we have the subchannels) and accurately preserve the subchannels, which we're not doing..
Yes, we should think about adding the subchannels. But it's not possible with the current db, you can't assign more than one subs dump to a single entry now (while the same title usually has different subs on different pressings).
We're already adjusting the dump data to remove offset mastering effects, so why shouldn't we do the same for gaps and only record any subchannel discrepancies instead of applying them to the dump data?
People, what 'offset mastering effects' are you talking about? 
I've thought, at least our mods do understand the main concept, look like I was wrong.
We round things up because THE SOFTWARES THEMSELVES ROUND THE THINGS UP, wheter they like/dislike the drives, whether they like/dislike the subs, wheter they like/dislike that particular disc.
The main problem is that there's currently no proper subchannels-dumping tool, able to verify each sector and reread it, if its AMSF is incorrect or Q-CRC doesn't match (I'm not talking about subchannels-based protections now).
Good luck waiting for a proper subchannel reading software. We waited for it for at least 15 years, back then when CDs were still current technology. Now that they are last century technology, who exactly will try writing it?
Nobody could write a proper tool when CDs actually meant something as a media, moving money... surely we won't get it now that most of the world use them as beer mats.
And exactly how would a subs tool work? You'd call viable a tool that takes 3 months to get 1.238.980 different subs reads to find out that none of them match? Unless in the last year suddenly subs transformed into redundant data that can be read consistently.
As things stand now, subs are a non-issue, they can't be read in an emulation worthy way. Probably never will.
Your method of checking gaps with a few drive/soft setups and using the one that comes out the most isn't less random than checking actual gap sectors and realizing that for every PCE and MCD CD out there the gaps are always 0:00/2:00/3:00 secs long, whatever the dumping method. If we try 12 different setups and we get X sec gaps 7 times, should we discard the 5 times we got Y/W/Z sec gaps?
I don't get why settling for gaps checked by programs with arbitrary reading routines on CDs printed with mastering machines which were new when Bruce Willis still had hair should be called THE proper way to do things. Again it's not less random than every other way.
You know, what your problem is? You don't want to read my explanations, you just ignore everything and repeat the same things every time, like a parrot.
When EAC meets the EAN sector between 2 tracks, it assumes this sector belongs to the next track, while in reality it belongs to the previous one.
EAN sector usually replaces one of the real sectors. Sometimes, it may replace the very last sector of the track or the very first one:
...
When EAC faces this situation, it always assumes this EAN sector belongs to the next track (Track#10 here), while it can belong to the previous track (#09), too (this is described in the IEC 60908). It's one of the EAC bugs and it's not drive-dependant, it works like this even with virtual drives, so it's about decoding the subs manually, not 'looking for the correct drive' and not about 'fixing the gaps'. I hope you won't touch this thing anymore.
i do ignore indeed most of what you post, because you keep evading direct answers
by repeating same general defenitions over again.
i believe everyone here is aware of problems associated with those EAN cases.
now could you demonstrate, please, using this very same example you gave,
how exactly will you tell to which track middle section belong?
01 09 01 02 20 10 00 15 57 12 49 CC
01 09 01 02 20 11 00 15 57 13 F3 BC
02 00 00 00 00 00 00 00 00 14 73 C0
01 10 00 00 01 73 00 15 57 15 08 9F
01 10 00 00 01 72 00 15 57 16 92 ADand while doing so, please keep in mind what you wrote:
We don't correct any gaps, stop imagine things. We can only refuse results from one of the tools, when it's known it has a bug. But we never fix any gaps, just because we don't like them and all the other CDs on this system have different beautiful rounded gaps.
As for the offset, I repeat, you can't dump the CD without fixing it, because the post-data audiotrack will have the garbage, you can either fix the offset or cut the pregap out to mask it (like CDRWin does). So it's not about assuming the values, it's just about dumping the _proper_ range.
or replace garbage with $00, not at all do we need to correct offset
btw, correcting offset will not eliminate garbage, we do it anyway.
and what about Audio CDs?
do you recall this topic, F1ReB4LL?
http://forum.redump.org/topic/3492/akum … audio-cds/
there is no garbage to fix in Audio CDs, yet you seemed so excited about idea of getting CDDA offsets right
you went then and made several posts in Rocknrom's Saturn thread the same day regarding this subject:
http://forum.redump.org/topic/3152/ss-s … 08/page/3/
have you changed your mind since then, F1ReB4LL?
do you think now that there should be 2 entries for that particular CD? - as no data appears to be lost
I repeat, the most important thing is to read the whole 'Data' range from the first byte upto the last, without any cuts, TOSEC fails at that point. Eliminating the clones is a nice bonus, but it's not about targeting at eliminating them. OK, a few examples:
1) http://redump.org/disc/2597/ -- by your logic we should round all the 00:01:74 gaps here to 00:02:00.
2) http://redump.org/disc/5194/ -- by your logic we should round all the 00:02:02 gaps here to 00:02:00
3) http://redump.org/disc/5263/ and http://redump.org/disc/3661/ -- same CD, but the offset is 0, audiotracks are the same, but shifted, by your logic we should find the offset _somehow_ and merge the entries.
4) http://redump.org/disc/3717/ -- this CD contains a standard 10-secs warning, but in this particular case it was shifted during the mastering and misses some samples at the end. By your logic we should replace it with the known 10-secs warning instead of the one written on the real CD, because it was corrupted during the mastering.
5) http://redump.org/disc/3376/ and http://redump.org/disc/5266/ -- audiotracks have a 1-sectors length difference, we should also fix it, right?etc, etc, etc. I'm afraid this won't be about the proper dumping anymore, just about the assuming (actually, assing everyone).
unfortunately i'm not familiar with Saturn, i'll be able to discus this in few months
for now let's stick to the topic (2:74<>3:00 for PCE only in subcode), shall we?
Fixing the very last pre-audio Mode2 track is necessary, it's not about mastering issues, it's about most of the drives read this sector incorrectly (and differently every time). Some of the drives do read this sector properly, though, there's no need in psxt001z --fix for them. So you've chosen the wrong example again.
no, F1ReB4LL, this sector is invalid, hence some drives will not read it at all,
so it will be replaced with generic empty sector (please see dumping guide)
but some drives will read it as it is
psxt001z --fix does the same with data returned from those drives that could read it - replace with generic empty sector
it's very good example imho, because this procedure has no other purpose than to make data comparable
and in this case actual content is lost for this very same cause, yet you do not seem to object
As for the replacing sectors with $55 pattern - guess, this is about PC discs, dunno, I don't like the PC section at all, it's a pile of trash in its current state.
well, again actual content is replaced with generic data.
i see it as a clever solution myself, well since you don't, i'm looking forward to what alternative you are going to propose.
and finally could you answer to this one, please?:
in the end, when you separate 2:74 from 3:00 what will you gain?
Redump Forum → History for fixes → [DONE] [PCE] Road Spirits (J)
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.