Search options (Page 2 of 6)

Are you always detecting gaps before dumpigng with EAC? Even if it returns 0.00 it's necessary to hit F4 before dumping. Even without manually adding pregap, EAC resulting file shouldn't begin directly with data.

AFAIK PerfectRip should give right size track01 without resizing. If PerfectRip's untouched and IsoBuster's resized match, then it's right.

Track02 still has issues, I see that PerfectRip file still has less than 2.00 pregap, and EAC file still misses data at the beginning.

Can you look at actual disc lenght in sectors with IsoBuster?

Actually PerfectRip's track02 you uploaded has less than 2 second of pregap, and EAC's has exactly 352800 bytes of pregap (which are the ones you added), so it's probable that EAC cut some data at the beginning. I prefer to hear what Vigi/Dremora/Themabus have to say. A -924 offset is exceptional, maybe there's an issue with that.

Yes the combined offset is -924. That's the number to use (in PerfectRip it's +924)

EAC doesn't detect track02 pregap, so the resulting file has should have no pregap.

Try manually adding a 2.00 pregap to EAC's track02, and see if it matches PerfectRip's track02 in size and CRC.

I think Dremora is asking that because in both EAC and PerfectRip logs you posted above I see a +252 offset correction. Why that? Using your calcs the write offset is -954, and if combined offset is -924, you should use that to dump. +252 is completely wrong.

Moreover are you sure you have to subtract -1176 for this disc? The part of the guide you cited is only an example, you don't have to always subtract 2 sectors to get the offset. What number do you get after the sync? Is it really 018202? Or is it 18200? SegaCD discs shouldn't have big negative offsets.

First sector is basically a header, it would make no sense to change it without changing the actual game code. Hell, if true Saturn would be the only game system on Earth of the last 30 years to have different headers same code

Can you mail me your Track02? I want to do some tests.

Thanks

Ok it's fine I see your Track 35 is 2352 byter bigger, it makes sense since all the gaps are shifted.

Can you post your info on WIP?

A consideration, after Pepsidrinker dumps is tracks, if they match my Japanese disc but only with gaps shifted 1.74->2.00, it would be pretty clear that all these 1.74 gaps are only misjudgments from dumping programs caused by un-standard mastering.

It's not a case that Japanese discs with "normal" write offset (with normal I mean <100) report 2.00 gaps too, just like USA discs. See F1 Circus CD, Game no Kandume, Vay. When the offset becomes huge, then the dumping programs go mad and 1.74 gaps start appearing. Even official system documentation says minimum gap size for MegaCD is 2 seconds!

Maybe not tomorrow, but in the near future we should change all of them to 2 seconds, hopefully there will be an automatized way to do the process.

2 characters = 1 byte, so 24 characters = 12 bytes. Or you can count lines, multiply * 4 and then subtract sectors, in this case there are 139,75 lines before the sync.

If you dump with IsoBuster you have to take out the data track the full 352800 bytes, IsoBuster always sees 2seconds after the data track, so your data track size would match mine, the CRC are different of course because they're different region.

What about audio tracks? You should add 2352 bytes of silence at the beginning of track02.

In other words, IsoBuster puts 352800 bytes more at the end of the data track, but PerfectRip/EAC put only 350448 bytes of silence at the start of the first audio track.

Actually it is

(139 * 4) - (588 * 2) = -617