GoodSegaCD / GoodSaturn

[eidolon]

I know this question has probably be discussed before, but...


What about starting a GoodSegaCD and GoodSaturn project?


With having BIN/CUE dumps directly from the original CDs, MD5 checksumming them?


Naming convention could be e.g.

(SegaCD) Lunar - The Silver Star (U)[1].bin

(SegaCD) Lunar - The Silver Star (U)[1].cue

(SegaCD) Lunar - The Silver Star (U)[1].md5

(SegaCD) Lunar - The Silver Star (U)[1].7z (containing all the above files)


I remember this discussion from a few years ago, when PCs didn't have enough harddisk space - that's when the infamous ISO/MP3 rips where invented.


But now, with common desktops reaching the 1TB marker, it shouldn't be a problem to start with preserving the games in their original format.


Like the GoodGen project... Is Cowering still active in the scene?


Regards,

Eidolon

http://www.eidolons-inn.net

 

[ExCyber]

I think TOSEC is working on this, but their forum seems to be down, so I have no idea what the current status of it is.

 

[eidolon]

I think TOSEC is working on this, but their forum seems to be down, so I have no idea what the current status of it is.

Hey, that's good to know, I'll check out the TIM utility first.

But as you say, their last activity is from March 2007, so who knows... Maybe I'll start the GoodSegaCD/GoodSaturn projects on the Inn instead.

 

[eidolon]

Hey, that's good to know, I'll check out the TIM utility first.

Hm, I wonder why TOSEC has chosen the ISO+WAV+CUE format as basis? Isn't BIN/CUE the easier format, achieving the same result with less single files?


Anyway, the TIM utility is nice - I will try contacting them to see if it's still actively being developed.

 

[Madroms]

It was not previously done + TOSEC chose ISO+WAV+CUE because of the audio tracks and the offset corrections that must be applied.

You have some posts on the net about this, and one on your site that I found just now with google

http://www.eidolons-inn.net/tiki-vi...rumId=10&PHPSESSID=4nl3km8euqtdnump625bptoll1

I really prefer bin/cue raw mode myself but no software allows to rip cd in bin/cue raw mode WITH offset correction.

 

[eidolon]

It was not previously done + TOSEC chose ISO+WAV+CUE because of the audio tracks and the offset corrections that must be applied.

You have some posts on the net about this, and one on your site that I found just now with google

http://www.eidolons-inn.net/tiki-vi...rumId=10&PHPSESSID=4nl3km8euqtdnump625bptoll1

I really prefer bin/cue raw mode myself but no software allows to rip cd in bin/cue raw mode WITH offset correction.

Wow, THANK YOU for pointing me to that particular thread on the Inn - the one I was looking for, but somehow unable to find .


Well, I re-read the discussion, and there was some issues about audio offset between Steve Snake and another guy named vasya_pupkin.


But the conclusion of all (actually, Steve's conclusion) was that BIN/CUE rip is still the best way to go.


And I'd rather trust Steve's knowledge here than that other guy's one.


All the BIN/CUE rips I've done from my original Sega CD's so far are perfectly synched in both Gens/NeoGenesis and Kega. What more can I ask for?

Actually I did some testing following vasaya_pupkin's argumentation, and ripped my Panic! disc (badly scratched, lots of audio tracks) in BIN/CUE format using two different DVD drives - but the MD5 checksum of the resulting BIN file was the same.


So, for me, the rip method of choice will be BIN/CUE - that's a lot easier to maintain anyway (less files to cope with).

 

[Madroms]

What are your DVD Drives ? They have probably the same sample offset so the .bin has the same crc/md5.

The problem is not about synch problems (audio tracks will be always at the same LBA) but more of the sample offsets (real audio data, inside the data track, will have some shifts of some bytes).

Let me know the dvd/cd drives you have, so we can check their sample offsets.

The big problem is drives don't have the same sample offset, check the db at accuraterip: http://www.accuraterip.com/driveoffsets.htm

So people with the same game cd but with drives with different sample offsets will produce different CRC/MD5 for their .bin. The best is to try this by yourself but you need 2 drives with different sample offsets.

==> CRC/MD5 database is useless because of this, unless someone make a bin/cue ripper with offset correction for audio tracks.

 

[eidolon]

http://www.accuraterip.com/driveoffsets.htm

Thank you for this information, that was really new to me. I'll have to recheck the comparisons I've made - I think I might have made the comparison with a game with no audio tracks....


I will now do further testing... And hope there is a program that can correct the offset in my already made BIN/CUE rips (I already did about a dozen), after I know the offset of my drive.

 

[eidolon]

Ok... I now ripped Monkey Island and Road Avenger eight times:


- using Alcohol 120%

- using UltraISO

- using my Thinkpad's Internal DVD drive (Hitachi-LG GSA-4083N)

- using my external DVD drive (IBM USB2 Multiburner)


Four different rips for each game, four different .BIN files, four different MD5 hashes.


Something funny happened with Alcohol 120% - the ripped images always have a 2-second "pregap" between the data track and the subsequent audio tracks. UltraISO doesn't produce that gap. Why is that?


Anyway, I concede defeat... BIN/CUE is not a good format to preserve games for posterity. CUE/BIN/WAV after offset correction (as per accuraterip.com) definitely seems to be the best way to go. Damn, now I have to either re-rip my collection, or find a way to normalize (apply the offset correction) my BIN/CUE rips...


One thing I wonder though - shouldnt the audio offset of CD drives be a problem with the real hardware as well? If Sega used different CD drives (or even different firmwares) in the various Sega/Mega CD models, there should be synch issues as well...

 

[TascoDLX]

Ok... I now ripped Monkey Island and Road Avenger eight times:


- using Alcohol 120%

- using UltraISO

- using my Thinkpad's Internal DVD drive (Hitachi-LG GSA-4083N)

- using my external DVD drive (IBM USB2 Multiburner)


Four different rips for each game, four different .BIN files, four different MD5 hashes.

It's hard to tell where the problem is if you don't know where the .BIN files differ. Personally, I'd use HexCmp to determine if the data differs or if it is just an offset problem. I'm sure there are other programs that can do the job just as well.


If a disc is very dirty or scratched, then it's possible that one or more audio tracks can't be accurately ripped. The drive will interpolate the audio so that the listener can't tell there was a problem reading it. Some older drives just can't rip audio accurately at all. Hence, the need for AccurateRip and programs like Exact Audio Copy.

Something funny happened with Alcohol 120% - the ripped images always have a 2-second "pregap" between the data track and the subsequent audio tracks. UltraISO doesn't produce that gap. Why is that?

I don't know about UltraISO, but CDRWIN doesn't include the gap between the last data track and first audio track. It will instead write the .CUE file so that the gap is reconstructed, usually with the PREGAP command. Other programs such as CloneCD will copy the gap, but it's mostly if not entirely zero data as the standard (ECMA-130) deems it.

One thing I wonder though - shouldnt the audio offset of CD drives be a problem with the real hardware as well? If Sega used different CD drives (or even different firmwares) in the various Sega/Mega CD models, there should be synch issues as well...

The offset is measured in samples. At a sample rate of 44100 Hz, the offset would have to be huge for there to be any noticible synch issues.

 

[Madroms]

Ok... I now ripped Monkey Island and Road Avenger eight times:

- using Alcohol 120%

- using UltraISO

- using my Thinkpad's Internal DVD drive (Hitachi-LG GSA-4083N)

- using my external DVD drive (IBM USB2 Multiburner)

Four different rips for each game, four different .BIN files, four different MD5 hashes.

It is normal: 2 drives with diff sample offsets and 2 softwares with different ripping method, see below. And also, it could be scratches cd or one of your drive can't make accurate rip of audio tracks, so you will have some bytes that differ.

Something funny happened with Alcohol 120% - the ripped images always have a 2-second "pregap" between the data track and the subsequent audio tracks. UltraISO doesn't produce that gap. Why is that?

As TascoDLX said, some software copy the gap between data and audio track, some don't. UltraISO and CDRwin do NOT copy this gap and instead they write on the .cue file the "PREGAP 02:00:00" line just between the data track and the audio track (see CDROM standard for more info about pregap between different types of tracks). BUT Alcohol rips the gap, so your .bin will be 2*75*2352 = 352800 bytes larger than a .bin created with UltraISO.

Alcohol is not the best ripper (not really because of the gap ripped, but because of some problems on some specific CDROM structure).

Ripping the gap or not, what is the best ? It will depend on which type of CDROM you want to copy. For Saturn and SCD, not ripping the gap is OK, unless you have a drive with a big negative sample offset. In this case, the audio data will begin in the pregap if you rip your cd in bin/cue.

One thing I wonder though - shouldnt the audio offset of CD drives be a problem with the real hardware as well? If Sega used different CD drives (or even different firmwares) in the various Sega/Mega CD models, there should be synch issues as well...

No synch problem, as TascoDLX said, we are talking about samples only. 1 sample = 4 bytes, where 1 sector = 2352 bytes = 588 samples = 1/75 second (1 second = 75 sectors = 44100 samples = 176400 bytes).

Don't forget there are also sample offsets due to the press machine used.

About SCD and Saturn discs, some games have been pressed on different machines with the same "master", so for the same game you can have different pressed cds which produce different rips (with the same ripping tools+drives). This is the case for Daytona USA european version for example. A few machines were used by Sega to produce this game. They used the same "master" but as each press machine had its own sample offsets, ripping those CDs will result in different CRCs, despite they come from the same game (but not the same cd).

To have the "id" of the press machine used for the cd, check out the matrix information.

For ex, for Daytona USA EUR, on my db (not updated for a long time), I already have 2 different matrix recorded, so 2 different press machines used: http://madroms.free.fr/db/index.php?od=330&text=MK_8120050-Daytona-USA-EUR-MK81200-50

If you want a guide to rip your cd, check the one at www.redump.org I find this is the best guide we can have for ripping game cds, but not really easy to do for a huge amount of cds.

I am waiting for someone who can make a ripper with offset correction and bin/cue raw mode support. I can't rip my 3000+ cds with the redump.org method unless I have 1 year with no other work(s) to do.

 

[eidolon]

It's hard to tell where the problem is if you don't know where the .BIN files differ.

It seems it is mostly an offset problem. Comparing the four Monkey Island dumps, the main differences were:

- The BIN dumps from Alcohol 120% are always 352800 bytes longer than the ones from UltraISO. Obviously, the 2sec PREGAP data is not only in the cue sheet, but inserted as real data ("00") into Alcohol's BIN file

- Taking the end of the data track as reference, in both the Alcohol and the UltraISO dumps the beginning of the audio tracks section is offset by 2260 byte for the dumps from the two different DVD drives, apart from that offset, the complete audio track datas minus the offset is the same in all eight dumps.

I don't know about UltraISO, but CDRWIN doesn't include the gap between the last data track and first audio track. It will instead write the .CUE file so that the gap is reconstructed, usually with PREGAP

UltraISO behaves in a "third way" - it simply ignores the pregap and neither reads out the 2sec of 0x00 data, nor does it mention it in the CUE file....



So the question remains - who is setting a standard on how Sega CD and Sega Saturn CDs should be preserved for best possible conservation?

- Do we just pick one to kick off the GoodSegaCD/GoodSaturn project?

- What kind of toolset is there available which creates the CUE/BIN/WAV files from the CDs easily? To me it currently seems a combination of tools has to be used, which is very cumbersome.


Too bad the TOSEC forums are down, maybe they have the answer...

 

[eidolon]

If you want a guide to rip your cd, check the one at www.redump.org I find this is the best guide we can have for ripping game cds, but not really easy to do for a huge amount of cds.

I am waiting for someone who can make a ripper with offset correction and bin/cue raw mode support. I can't rip my 3000+ cds with the redump.org method unless I have 1 year with no other work(s) to do.

Thank you for your clarifications!


I more and more see it is a futile attempt. I don't have 3.000 CDs, only about 50+ each for SegaCD and Saturn, but anyway it's a lot of time to dedicate.


So, we have tosec.org and redump.org with the same mission.


Unless this clarifies/consolidates itself (and, as you say, confortable accurate ripping tools suitable Sega CD and Saturn are available), I hereby cease my efforts of dumping my original games in any other format than BIN/CUE.


My drive definitely has a positive sample offset.

So I'll simply rip all my CDs in BIN/CUE with the same drive, take note of the sample offset of my drive, and hopefully later on some tools will be available to take that information to split the file in 1 ISO plus x WAVs with corrected offset.


That way, I can be reasonably sure that I still have digitial backups of my SegaCD+Saturn CDs in case the originals die, and I could contribute checksums or files to the community later on if it becomes necessary.

 

[Madroms]

Unless this clarifies/consolidates itself (and, as you say, confortable accurate ripping tools suitable Sega CD and Saturn are available), I hereby cease my efforts of dumping my original games in any other format than BIN/CUE.

Exactly what I do/did. Today, too much time and effort for some sample offsets => no way for me. I hope we will get a really good and reliable tool in the future.

So I'll simply rip all my CDs in BIN/CUE with the same drive, take note of the sample offset of my drive, and hopefully later on some tools will be available to take that information to split the file in 1 ISO plus x WAVs with corrected offset.

That way, I can be reasonably sure that I still have digitial backups of my SegaCD+Saturn CDs in case the originals die, and I could contribute checksums or files to the community later on if it becomes necessary.

The only problem (again) that you will have is the last audio tracks will be missing some samples (found in the lead-out), sometimes it is just some 00 (so easy to add them after), sometimes it is data (no way to recover them unless you rerip your last track after all).

All these sample offsets give us a lot of work and headache, just because they didn't think at first that audio data needs some sort of pointers/headers/what else. "oh, it doesn't matter for audio to have some missing samples, you can't hear the difference!". Yeah It all depends on your needs. Standards are like that, sometimes they were ok some years back, but are not so well defined for today's purpose.

 

[eidolon]

The only problem (again) that you will have is the last audio tracks will be missing some samples

Aaaah I didn't think about that... Ok, there's ONE easy solution... Get a DVD drive which reliably reads audio tracks with a sample offset of 0! ;-)

 

[eidolon]

for information, I discussed the issue further at the Inn with Steve Snake Tavern Thread.


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.


So, I'll simply go ahead with dumping my collection as BIN/CUE using CDRWIN, taking note of my drive offset (+667) and will that way have an almost-perfect dump from my original CDs which works perfectly in emulators, can be perfectly reburned to work again on the original machine, with the slight drawback that there MIGHT be as many as 667 samples missing from the end of the last audio track of a particular game (which in probably 99.9% of all Sega CD games won't make a difference).


Case closed.

Or is it ever...