626

(55 replies, posted in General discussion)

I think the most important reasons for dumping data tracks in RAW 2352 are:

- no Frankenstein dumps like gigadeath said.. the full main channel is dumped.
- you can easily combine the tracks of a dump that were done using the Redump method into a single image using copy /b. Then you have a proper image of the complete cd with correct gaps and offset. This wouldn't be possible with 2048 tracks without converting them to 2352 first.
- the extra error correction data can be used to verify that the track data is correct (without having to dump the track twice).

I really don't know why 2048 would be better than 2352 (it's smaller yes, but what else?). Maybe you could include both 2352 and 2048 checksums in your database, but this would only take you more time.

627

(55 replies, posted in General discussion)

chungy wrote:

(Technically speaking, redump.org DVD images are all wrong since they don't include raw DVD sectors, which is far more difficult to access and not all DVD drives do it in the same manner (essentially every vendor has their own proprietary commands); who's to say that non-chipped PS2s actually check data that's not in the 2048-byte user data area of a DVD sector?)

You're right, RAW reading DVD's IS possible, but it's very difficult to accomplish: http://x226.org/?p=17 . I think the PS2 reads the DNAS ID in a special way (it should be in the user data area when extracting but it's not). Anyway, there's no point in including the DNAS ID either, because it can be injected after and the images can't be verified when it's included (I think).

If anyone has some info on extracting DVD's 2064 bytes/sector using custom firmware, and what the advantages are, plz let us know smile


Offtopic:

ps. after some google'ing I came across this thread: http://assemblergames.com/forums/showth … p?p=253548
I have a Datel PS2 cd here that has unreadable sectors in the same region, maybe it's possible to extract them in d8 and create a bootable copy big_smile

edit: I managed to extract the sectors and get the same patterns as the other guy, but according to this thread http://club.cdfreaks.com/f52/how-datel- … on-147005/ this data has no real purpose after all

628

(55 replies, posted in General discussion)

daishadar wrote:

Dear lord, as someone who's spent a decent amount of time archiving TOSEC dumps, this information is very disturbing.

If you diff'd a TOSEC ISO dump and a Redump dump, any idea how different the two files would be?  If the difference is very small then it should be possible for someone with a full set of both dumps to create patch files to convert individual TOSEC dumps to Redump dumps.  This way, TOSEC dumps could be merged to more accurate Redump dumps over time.

It's amazing that it is this complex to create 1:1 backups of CDs.  It's just astounding.  Did the original creators of the ISO 9660 standard never see this coming?  From a high level perspective, CDs just store bits- just read all the bits off of it!  smile

In short all data-only dumps like 3DO are easy to convert if you for instance mount the cuesheet in daemon tools and then raw extract.

The problem with adjusting the audio is that you'll have to know the write offset of the original disc. With systems like SNK Neo-Geo CD this is often pretty easy to detect from the image itself, because the audio data always tends to starts at a certain position in the track (for instance if the audio data would start 2 samples after the start it was safe to conclude that the write offset was +2, which is also a common PSX write offset).

Other discs with larger write offsets have a pretty big chance of having missing samples at the start or the end of the audio. When I helped a TOSEC guy to convert the SNK set to the Redump format once we came across several discs that needed audio redumped because there were samples cut off at the start or the end. I think other systems like Saturn will have similar issues. Of course it should be possible to create a patch, but it would only make sense just to convert TOSEC dumps to Redump ones for collecting purposes (and for saving bandwidth).

If a TOSEC dumper should care about the accuracy of his dumps, he could always come here and redump them using the better method. We will never convert/steal any dumps from other projects. I know that some of the TOSEC dumpers are aware of the differences, but they don't seem to care enough about them to start redumping. Maddog from TOSEC once gave me the same explanation as Eidolon did a couple posts before: who really cares about 1/75th of a second?.. I think this thread makes clear that we are the only project atm that DOES care.

themabus wrote:

oh that would be great, even if for a short time while i get my pce cds done

short time? heh.. you're one of the biggest contributors.. I think moderator status is the least we could give you

slightly offtopic: do you also have SNK Neogeo CD discs?

edit: Dremora gave you moderator and added delete function, but I already deleted the dupe PCE for you smile

630

(55 replies, posted in General discussion)

I agree that there's no real point in switching to a poor man's way of dumping cd's just because the other one presumably takes a bit longer.. but I do like the 'smart checksumming' idea that you came up with (checking the data integrity of a cd or image on-the-fly by comparing blocks). However I agree with themabus that without read+write offset correction you will soon run into problems where the start and the end blocks of the audio will have missing data, thus making crc comparison impossible. Also, if I recall correctly, the usual cue/bin tools out there (not sure if this includes cdrwin) don't append the gaps correctly and skip the track02 pregap just like old EAC versions are doing, so the chance of missing samples will be even bigger.

As for scratches and not being able to dump audio correctly: EAC's error detection and rereading mechanism is pretty decent and helped me through a lot of scratched cd's that would be impossible to dump correctly with conventional tools like cdrwin. Also, you forgot that C2 can also be used to detect errors (PerfectRip uses C2 to check for corruption).

themabus wrote:

ok, i resubmited everything +2 new cds but only crcs for data tracks should change
i'll keep checking every cd for that exact data sector number in gaps, not assuming 150 <- scrap that, let's do it perfect smile

woops.. now the db is a mess sad I wish you just could have edited the old entries.. Dremora should definately give you moderator rights and perhaps remove -v- and cHr from this status because they're never around (anymore)

632

(55 replies, posted in General discussion)

There is no such thing as "intelligent checksums". There has to be a standard of how reference checksums are calculated before you can disregard the data offset. We prefer to take both the read and the write offset into account when determining the reference, allowing audio tracks (when saved using the standard) to have identical checksums across different regions/games and not just to look at the data integrity the way you are planning to do. It makes me wonder if the benefit of speed will really be that great, because even a minor small scratch on any of your cd's will give you problems dumping and verifying them the 'fast' way. Sooner or later you will propably end up using EAC after all. Anyway, good luck with your projects.

As for GoodGen, I like No-Intro's dat better, because it's more accurate. Then of course I'm not even talking about MAME and how they want to preserve the Sega Genesis roms (splitting the data into separate files exactly like they are stored on the actual rom chips). Most people also consider this 'pointless' while others don't (see the resemblance?).

Have you set it to Action > 'Append Gaps To Next Track'? And make sure you always do Action > 'Detect Gaps' after inserting a new disc

It shows a gap of 0 seconds instead of 2 for the audio track on the screenshot, so maybe it failed to detect.. Other discs shouldn't have this problem

Are you using the latest version of EAC?

634

(55 replies, posted in General discussion)

Also, the replies I got from the guys at redump.org leads me to the conclusion that it is simply too much hassle to go after "perfect" dumps. There is no such thing as a perfect dump.

Taking Eidolon's quote from his forums, I think he misinterpreted my post. We DO believe that our method creates perfect dumps. Perfect in the sense that every single byte of data on the cd is secured (except the lead-in, lead-out and subchannel data which are irrelevant).

To sum up the differences again between our method and the TOSEC one:

- TOSEC extracts the cooked 2048 data track from a raw image, dropping 304 bytes of information in each data sector that are on the cd (many systems like PSX require the complete main channel, so all 2352 bytes/sector to be ripped, there's no real point in having a 2048 bytes/sector data track for preservation, regardless of what other people say.. audio is 2352 bytes/sector and so is data).
- TOSEC leaves out the track02 pregap, because older EAC versions were not capable of dumping it. This pregap can contain relevant data which will be left out in the resulting dump.
- TOSEC adds a 44-byte RIFF (wav) header to each audio track that isn't on the cd.
- TOSEC corrects the read offset only. Redump corrects both the read and the write offset, allowing audio tracks to be put back into the position they were BEFORE manufacturing. This has proven to be a more senseful way of dealing with audio than just correcting the read offset, because after read+write offset correction we now have audio tracks that start exactly at the intended position (often right after the pregap at byte 352800 for instance) and that have matching checksums across different regions for discs with different write offsets (these tracks would have different checksums using the TOSEC method). Some examples: http://redump.org/disc/1777/ http://redump.org/disc/447/ , all Mortal Kombat Trilogy versions, and lots more.

If you still think it's too much work for you (even with PerfectRip) then that's alright. I just wanted to explain why we believe that our method IS perfect. Perfect in the sense that the full contents of the cd are preserved the best possible way. There is still room for improvement for the speed and difficulty of the dumping process, but the output that is achieved is final.

635

(55 replies, posted in General discussion)

Welcome

We've tried working together with them in the past, because we too felt it would be better to have one database for all dumps. TOSEC however didn't want to give up on their dumping method, because redumping all their discs using our new method (raw data tracks, write offset correction on audio, no riff headers added to audio) wouldn't be possible.. (we were told that a lot of the discs that were dumped could not be redumped anymore because they were already sold again etc..) Also there have been some differences in opinions on what's the best way to dump discs, which lead to some arguments between certain members.

With that said, a decent amount of people who dumped for TOSEC have also dumped PSX games for our project. We've added new systems over the past months not to try and replicate what TOSEC is doing, but because there were demands of people who wanted to dump the discs with what they believe is the best method. This is because CD dumps from TOSEC (except the data-only ones like 3DO, of which the error correct data can be generated) sometimes have missing samples in the first and the last audio tracks (that couldn't be dumped due to EAC limitations and lack of write offset correction.. TOSEC doesn't think of this as a big deal but we do, because we want perfect 1:1 dumps, even if it's just a few bytes).

I'd still recommend people with Dreamcast discs to team up with TOSEC for that, because they're better organized at that (we have 4 dumps and they have hundreds). The only different for that system is the write offset correction, which in the end only comes down to some shifted bytes.

As for automated tools, the only one we have so far is PerfectRip. The version that we are testing was abandoned and the new version won't be out for aprox. 6 months. Anyway the version that we are testing works pretty good on Plextor drives, so if you have a plextor drive I could send you a test version (unfortunately other brands don't seem to work that well).

It's not much use comparing the two dumping methods (Redump vs TOSEC), because (as harsh as it may sound) we consider their method to be obsolete. We started out with a method that was almost identical to TOSEC's. Then soon after we discovered how to detect the write offset of a disc and how to correct is. The current method is final, even though there's still room for improvement in the speed area. Once you get used to it it will only take a couple of minutes for each disc to dump (unlike EAC, PerfectRip can automatically rip data and audio tracks with the correct gaps).

ps. for SegaCD dumps we work together with the no-intro project - http://gbadat.altervista.org/

ps.2 A google search for redump.org brought up this topic: http://forums.segaxtreme.net/showthread … amp;page=2 so I assume that's where you came from smile if you you have any more questions let us know

636

(4 replies, posted in Fixes & additions)

gigadeath wrote:
pepsidrinker wrote:

Sorry, these games I dumped before I knew about cue and mode1 and that, sorry. Please change it from Mode 2 to Mode 1, thanks again I apologize.

Yeah PC games can be either Mode 1 or 2.

You have to put into the database the exact cue you get from actual CD. Did you submit the same cuesheet for every disc?

Obviously he didn't tongue

637

(4 replies, posted in Fixes & additions)

IBM isn't always mode1, so I hope you checked all of them

and what about this one?: http://redump.org/disc/2072/

638

(2 replies, posted in Fixes & additions)

Thanks, but the volume serial number is only needed if region, version etc are the same.. so the time I asked you for it was an exception

themabus wrote:

oh, i see smile

but can you make a sugesstion, then? it's just that i thought about all of this and i guess there is no perfect way - machine would still make a wrong assumption at some circumstances, no matter how good algorithm is. so if they could make an interface to allow users to redefine gap layout in PerfectRip, this would solve a lot.

the delphi version that we are using isn't actively worked on anymore.. I'll pass it on as a suggestion for the future version

themabus wrote:
Vigi wrote:

We could always wait for the perfectrip successor and hope it will work on all drives

but i thought you're one of the developers, aren't you?

lol no way, I was just the one handing out all the beta's..

We could always wait for the perfectrip successor and hope it will work on all drives

I made this green because it matches the checksum of the Return.to.Castle.Wolfenstein.Game.of.the.Year.Edition-CURE warez release..
same for soldier of fortune platinum (it matches Soldier_Of_Fortune_Platinum_Edition-iVEiSO)

http://redump.org/disc/2257/

hey, did you forget to remove the pregap at the end? because the only difference between the original version entry is 150 sectors of the data track: http://redump.org/disc/1573/

644

(1 replies, posted in Fixes & additions)

That may be.. but it has to be part of the filename, because it's different from the normal version (it's password-protected).. the edition field doesn't add anything to the filename

645

(5 replies, posted in News)

Merry Christmas everybody!

ps. the database is nearing 2000 dumps. A special thanks to all the people who made this possible. We hope 2008 will be a good year again for preservation!

646

(2 replies, posted in Fixes & additions)

I added them the way they were submitted.. if it's incorrect you can edit them yourself

ssjkakaroto wrote:

I don't know if I'm doing this correctly but here's my result:
Sector 1: 18201
Sector 0: 18200
Sector -1: 18174
Sector -2: 18173 <- The one I got with px_d8
...
Sector -140: 18010
Sector -141: Error, LBA out of range

Is there really a 2 sector difference making the factory offset 1176? And why could I go up to -140?

there's 150 pregap sectors before the start of the data track, but they aren't dumped (because they don't contain any real data and because most drives can't read the entire pregap)

was 'apply YB scrambling' enabled in cdreader?.. and have you tried checking the offset the old way (does it have audio tracks) to see if it gives the same output of +1176?

I still can't be sure about the write offset, because +0 would make more sense than +1176 (is the accuraterip offset for your drive really +98?)

ssjkakaroto wrote:

Thanks Vigi, I don't know why I multiplied 24*8 instead of 16 hmm
But what about that 18173 thing that themabus mentioned?

You'll have to see for yourself if there's really a 2 sectors difference with your drive+disc:

Vigi wrote:

The best way to figure out the sector correction for such discs is by using Truong's cdreader tool: http://www.cdtool.pwp.blueyonder.co.uk/ … 1_2b20.zip .

Use 'View Sectors' to go to the first sector of the data track, then enable the 'Apply YB scrambling' box. This will scramble the header (the sync/header is now the same as the px_d8 output). Then you can determine the offset in sectors by looking for the sector with the same sync/header in cdreader.

ssjkakaroto wrote:

Hey guys lemme know if I'm doing the correct calculations here.
I got the following output:

028801A6807AE0230819C68AD2E71D8A
89A726FA9AC32B11DF4C5835FA97032E
81DC6059E83ACE93146DCF6D942DAF5D
BC39B1D2F45D8779A2A2F9B982F2E185
886326A9DAFEDB005B403B7013640DEB
458F732425DB5B1B7B4B637769E6AECA
FC5701FE8040603032407802486436AB
56FF7EC020A544C90A91C72C529DFDA9
81BEE0704824369B56EB7ECF6054283F
5E90386C12ADCDBD95B1AF347C1761CE
A8547EBF607028241E9B486B76AF66FC
2AC1DF10580C3A85D3231DD9C99AF817
B445485436BF56F03EC410A762C9F5D1
871C6289E9A6CEFAD4431F71C824569B
7EEB604F68342E975C6EB9EC72CDE595
8B2F275C1AB9CB32D7559EBF28701EA4
087B46A372F9E582CB2197586EBAAC73
3DE5D18B28CF85EDB6CF36D416DF4ED8
34F4977B2EA35C79F9E2C2C99196EC6E
CDEC558DFF25CACB7C9257BB6377A321
B9D872DAA59B3B2B535F7DF821820804
E22BA776A0BF780C2285D9A31AF9CB02
D7419EB068742EA75C7A95BEDE8E38D1
F273D81C5A89FB26C35AD1FB1C4349F1
F6C48A43145F4F2400FFFFFFFFFFFFFF
FFFFFF00018173610028001E80086006
A802FE8180606028281E9E886866AEAA
FC7F01E0004800368016E00EC8045683
7EE1E0484836B696F6EEC6CC52D5FD9F
01A8007E80206018280A9E8728629EA9
A87EFEA0407830229419AF4AFC3701D6
805EE0384812B68DB6E5B6CB36D756DE
BED8705AA43B3B53537DFDE181886066
A82AFE9F0068002E801C6009E806CE82
D4619F68682EAE9C7C69E1EEC84C56B5
FEF700468032E015880F26841AE34B09
F746C6B2D2F59D8729A29EF9A842FEB1
80746027681AAE8B3C6751EABC4F31F4
14474F72B425B75B36BB56F37EC5E053
083DC69192EC6D8DEDA58DBB25B35B35
FB57037E81E0604828369E96E86ECEAC
547DFF618028601EA8087E86A062F829
829EE1A8487EB6A076F826C29AD1AB1C
7F49E036C816D68EDEE4584B7AB76336
A9D6FEDEC058503ABC1331CDD4559F7F
28201E98086A86AF22FC1981CAE05708
3E869062EC298DDEE5984B2AB75F36B8
16F28EC5A4533B7DD3619DE8698EAEE4
7C4B61F76846AEB2FC7581E7204A9837
2A969F2EE81C4E89F466C76AD2AF1DBC
09B1C6F452C77D92A1ADB87DB2A1B5B8
7732A695BAEF330C15C5CF13140DCF45
94332F55DC3F19D00ADC0719C28AD1A7
1C7A89E326C9DAD6DB1EDB485B76BB66
F36AC5EF130C0DC5C593132DCDDD9599
AF2AFC1F01C80056803EE010480C3685
D6E31EC9C856D6BEDEF058443AB35335
FDD7019E8068602EA81C7E89E066C82A
D69F1EE8084E86B462F76986AEE2FC49
81F6E046C832D6959EEF284C1EB5C877
16A68EFAE4430B71C76452AB7DBF61B0
28741EA7487AB6A336F9D6C2DED1985C
6AB9EF32CC1595CF2F141C0F49C436D3
56DDFED9805AE03B0813468DF2E5858B
232759DABADB331B55CB7F17600EA804
7E836061E8284E9EB468776EA6AC7AFD
E30189C066D02ADC1F19C80AD6871EE2
8849A6B6FAF6C306D1C2DC5199FC6AC1
EF104C0C35C5D7131E8DC86596AB2EFF
5C4039F012C40D9345ADF33D85D1A31C
79C9E2D6C99ED6E85ECEB85472BF65B0
2B341F57483EB69076EC26CDDAD59B1F
2B481F768826E69ACAEB170F4E843463
5769FEAEC07C5021FC1841CAB057343E
97506EBC2C71DDE4598B7AE7630AA9C7
3ED2905DAC39BDD2F19D8469A36EF9EC
42CDF195846F236C19EDCACD9715AE8F
3C6411EB4C4F75F427075A82BB21B358
75FAA7033A81D3205DD8399A92EB2D8F
5DA439BB52F37D85E1A30879C6A2D2F9
9D82E9A18EF86442AB71BF64702B641F
6B482F769C26E9DACEDB145B4F7B7423
6759EABACF331415CF4F14340F57443E
B35075FC2701DA805B203B58137A8DE3
2589DB26DB5ADB7B1B634B69F76EC6AC
52FDFD8181A0607828229E99A86AFEAF
007C0021C018500ABC0731C29451AF7C
7C21E1D8485AB6BB36F356C5FED3005D
C0399012EC0D8DC5A5933B2DD35D9DF9
A982FEE180486036A816FE8EC064502B
7C1F61C828569EBEE8704EA4347B5763
7EA9E07EC82056983EEA904F2C341DD7
499EB6E876CEA6D47ADF631829CA9ED7
285E9EB86872AEA5BC7B31E35449FF76
C026D01ADC0B19C74AD2B71DB689B6E6
F6CAC6D712DE8D9865AAAB3F3F50103C
0C11C5CC5315FDCF0194006F402C301D
D4099F46E832CE95946F2F6C1C2DC9DD
96D9AEDAFC5B01FB40437031E4144B4F
777426A75AFABB033341D5F05F043803
5281FDA041B830729425AF5B3C3B51D3
7C5DE1F98842E6B18AF467076A82AF21
BC1871CAA4573B7E93606DE82D8E9DA4
69BB6EF36C45EDF30D85C5A31339CDD2
D59D9F29A81EFE884066B02AF41F0748
02B681B6E076C826D69ADEEB184F4AB4
37375696BEEEF04C4435F35705FE8300
61C028501EBC0871C6A452FB7D8361A1
E8784EA2B479B762F6A986FEE2C04990
36EC16CDCED5945F2F781C2289D9A6DA
FADB031B41CB7057643EAB507F7C2021
D8185A8ABB27335A95FB2F035C01F9C0
42D0319C1469CF6ED42C5F5DF8398292
E1AD887DA6A1BAF87302A5C1BB10734C
25F5DB071B428B71A7647AAB633F69D0
2EDC1C59C9FAD6C31ED1C85C56B9FEF2
C04590332C15DDCF19940AEF470C3285
D5A31F39C812D68D9EE5A84B3EB75076
BC26F1DAC45B137B4DE37589E726CA9A
D72B1E9F486836AE96FC6EC1EC504DFC
3581D7205E98386A92AF2DBC1DB1C9B4
56F77EC6A052F83D8291A1AC787DE2A1
89B866F2AAC5BF13300DD4059F432831
DE94586F7AAC233DD9D19ADC6B19EF4A
CC3715D68F1EE4084B46B772F6A586FB
22C35991FAEC430DF1C58453237DD9E1
9AC86B16AF4EFC3441D7705EA4387B52
A37DB9E1B2C87596A72EFA9C4329F1DE
C458537ABDE33189D466DF6AD82F1A9C
0B29C75ED2B85DB2B9B5B2F735869722
EE998C6AE5EF0B0C0745C2B311B5CC77
15E68F0AE4070B428771A2A479BB62F3
6985EEE30C49C5F6D306DDC2D9919AEC
6B0DEF458C3325D5DB1F1B480B768766
E2AAC9BF16F00EC40453437DF1E18448
6376A9E6FECAC057103E8C1065CC2B15
DF4F18340A97472EB29C75A9E73ECA90
572C3E9DD0699C2EE9DC4ED9F45AC77B
12A34DB9F5B2C73592972DAE9DBC69B1
EEF44C4775F2A705BA833321D5D85F1A
B80B328755A2BF39B012F40D8745A2B3
39B5D2F71D8689A2E6F98AC2E7118A8C
6725EA9B0F2B441F734825F69B06EB42
CF7194246F5B6C3B6DD36D9DEDA98DBE
E5B04B34375756BEBEF0704424335B55
FB7F036001E8004E80346017680EAE84
7C6361E9E84ECEB454777F66A02AF81F

24 full rows + 16 collums -> (192+8)/4=50 samples
..18173.. 2 frames behind from 18200 -> 2*588=1176 samples
Add the two -> 50+1176=1226 samples
My drive offset is +98 -> 1226-98=1128 samples (original write offset)

Is this correct?

24,5 * 4 (16 bytes for each row or 4 samples) = +98 instead of 50.. so it seems the write offset is 0

650

(13 replies, posted in General discussion)

First one: sync/header output indicates sector 3593, so you have to substract the difference in sectors: (521 samples before sync) - (3*588) = -1243 to dump

Second one: output indicates sector 101: (39 - 588) = -549 to dump

maybe themabus can verify tongue