1 Reply by MikuroK

(31 replies, posted in General discussion)

nocash wrote:

Yes, the no$emus, that was me. Newest one is no$psx (which got me into dealing with cdrom formats).

That's awesome, the first time I ever saw an emulator was back in '99 when I saw someone playing pokemon yellow in no$gmb.

It's interesting that you would want to support so many formats, personally i just mount my images and have my emulators access the virtual cdrom drive, which avoids the need for them to support them all. Though I suppose you're also doing it to learn how they all work, just the same as making a psx emulator...

Any chance you'll make it open source/linux compatible? tongue

Go to forum: General discussion

2 Reply by MikuroK

(31 replies, posted in General discussion)

Hi nocash.. wait, are you THE nocash? who made the no$ emus?

Anyway, check out libmirage, it's an open source library for cd/dvd rom image reading, and supports many common and uncommon formats, including MDS.

Hope it helps.

Go to forum: General discussion

3 Reply by MikuroK

(2 replies, posted in General discussion)

for compressed files (zip, rar, 7z...), probably the fastest way would be to grab the file listing from out of it with its corresponsing decompressor (if the format supports it)

$ unzip -l some\ game.zip 
Archive:  some game.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2012-12-04 01:20   some game.smc
---------                     -------
        0                     1 file

as for checking its hash, you would have to decompress the archive (unless you just use the hash stored with some archive formats)

$ unzip -p some\ game.zip | md5sum
d41d8cd98f00b204e9800998ecf8427e  -
$ md5sum some\ game.smc 
d41d8cd98f00b204e9800998ecf8427e  some game.smc

Go to forum: General discussion

4 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

PerfectRip, it's a good ripping program. Unfortunately, it needs a real Plextor drive for data+audio discs. For pure audio discs, any drive which can read directly the lead-out, if offset correction of drive is positive, is fine for PerfectRip.

Alright, sounds nice, but doesn't really apply to me, I almost never dump pure audio cd's, and it doesn't seem to work in Wine anyway (can't detect my drives, there could be a workaround, haven't tried anything).

Go to forum: General discussion

5 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

It's an EAC fault, which ignores the index 00 of a given track if previous track is data, and replace it with digital silence. If combined offset is negative you would like that EAC could rescue the lost samples pushed to index 00, but EAC doesn't do this, unfortunately. So, if you cannot run PF, the only options are the described.

I did as you suggested, more or less, I extracted the last 5 sectors of track 1, then copied the non-zero data from the end of it and joined it up just before where the zeros end at the start of track 2, and now it matches, so i have a complete and matching dump of Rollcage!

edit: what is PF, by the way? I misread it earlier as PR (perfectrip, from what i could tell).

Go to forum: General discussion

6 Reply by MikuroK

(41 replies, posted in General discussion)

So is that extraction procedure the only way with EAC when the combined offset is negative?

As for editions, these three particular discs are all originals, I have the packaging and manuals for them with me, too.

Wait no, Ridge Racer is platinum, but I think the scratches are the biggest issue.

Go to forum: General discussion

7 Reply by MikuroK

(41 replies, posted in General discussion)

Alright, I think i've got everything setup as good as it can be with my current hardware.

At this point i'm sure the errors left with Ridge Racer is down to the media quality, I'm thinking of investing in a resurfacing tool.

I've got Rollcage matching almost completely, with only track 2 not matching. Combined offset is negative (-635), and I get consistant results with 99.9%/no error reported in EAC, so I figure the drive just isn't properly reading back into the end of track 1, i'm not sure if there's anything i can do about that without a more capable drive, except maybe extracting the track out of a whole-disc image (I'll have to try that).

My freshly resurfaced MDK disc doesn't match whatsoever, I figure at this point it must be a different disc to the one currently in the DB, i'm a bit hesitant to post it as a dump though, not being able to get secure track 2's...

Thanks for the help, any ideas about getting the first audio track with my setup would be awesome, otherwise i'm sorted.

Go to forum: General discussion

8 Reply by MikuroK

(41 replies, posted in General discussion)

Well heck, testing the problem tracks in that version of EAC now;
track 7 is taking its time, but 2 and 6 are now matching!

This is with overreading still enabled.

I'll keep playing around with this version, and post in the morning, it's almost dawn hmm

Thanks again for the help, I've learnt a bit.

Go to forum: General discussion

9 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

When track quality for a track is <100%, there were re-reads, and EAC could obtain the same erroneous data 8, or greater, of 16 times. Try secure mode without C2 pointers, and burst. And do not enable overread if your drive cannot overread using EAC.

How can I check/test for overreading support? and is it not required to get all the data from the last track, in the case of a positive combined offset?

Obviously this disc won't be affected, since the last track is blank, but not many games use a blank final track.

I'll mess with no C2 pointers and burst mode now, with a problem track (6).

Any insight as to why EAC is putting the pregap at the end of track 2? it's the only reason why it's incorrect, if i move the pregrap manually, it matches.

Go to forum: General discussion

10 Reply by MikuroK

(41 replies, posted in General discussion)

The CRC mismatches were due to previous tests with the wrong pregap settings, so they don't mean anything.

Just finished a complete test+dump run, pic attached.

2,6,7,13,14 are not matching, though EAC only shows CRC errors for 6,7 and 13.

ugh, the log files are in UTF-16... disgusting.
http://pastebin.com/TP7ucStH (the log file)

I'll so the same tests in burst mode too, just to see what results I get.

Go to forum: General discussion

11 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

The DB ignores the standard and imperative pregap, of at least 150 sectors, of first track, which separes lead-in zone from program area.

http://img22.imageshack.us/img22/6715/pregaps.png Have your disc the same layout?

Looks like the same disc.

Go to forum: General discussion

12 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

What gaps are detecting EAC? The vast majority of PS1 discs has only 2:00 pregaps.

All 2 seconds, same as the DB

I edited my last post, you might miss it since we're on a new page, now

edit: actually.. it shows a 2sec pregap on the data track, but the db shows 0sec

Go to forum: General discussion

13 Reply by MikuroK

(41 replies, posted in General discussion)

Yes, it caches audio, but it's going at ~6.4x, which is fine with me.

I found the setting you mentioned a moment ago, and so far things are going well, but track 2 still has the pregap at the end of the file.

Edit: finished the disc, tracks 2, 13, and 14 are non-matching, less than before, but 2 is only wrong because the pregap is in the wrong place, and it somehow messed up 14.. which is a blank track...

Go to forum: General discussion

14 Reply by MikuroK

(41 replies, posted in General discussion)

Alright, I've installed and setup EAC, dumped track 2 with my SOHW-1213S.

It matches.. but EAC put the pregap at the *end* of the track, I looked around but couldn't find a way to make it preprend gaps (how does this even happen when I don't let it detect gaps?).

I verified it by stripping 2 seconds from the end of the track, appending 2 seconds to the start, then checking the md5.

The drive supports C2 error reporting, so that's nice.

Go to forum: General discussion

15 Reply by MikuroK

(41 replies, posted in General discussion)

EAC is known to work in Wine, but i'd rather stick to native/free software if possible.

I'm about to try the other drives now (probably won't bother with the compaq one though, it's from 1999). I'll try EAC, and also see how cdrdao by itself fares (it dumps cd's to a single image, from start to finish, which i can then split into tracks afterwards).

On a mostly unrelated note, do pure audio cd's have a write offset that I should be aware of? I imagine it would be trickier to manually find such an offset...

Go to forum: General discussion

16 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

Understood. Check if both are aligned. For example, use any hex editor, open both files and check if non-zeroed samples starts at the same offset. If so, do a binary comparison, which reveals differences. If not so, try fff -crc=$[The CRC32 of DB] -size=[Size according to DB] [INPUT FILE] [OUTPUT FILE, any name you want]. If success, your dump is the same of DB, but shifted. Perhaps, your drive fails sometimes to be accurate stream (just a hypothesis, nowadays this is really very weird, an accurate stream drive is a drive with constant read offset, as expected nowadays) and reads that track with another offset.

Well huh. I loaded track pairs 2 and 3 into a hex editor, and the versions are exactly 352800 bytes (aka, the pregap length) apart, the fixed one with the pregap silence, and the broken one with no pregap silence.

Looking closer at the rubyripper pregap detection, I notice that tracks 2 and 3 (note, rubyripper counts tracks starting from first *audio* track) aren't detected as having gaps, so that would explain those two tracks

Silence detected for track 3 : 150 sectors
Pregap detected for track 3 : 150 sectors
Pregap detected for track 4 : 150 sectors
Pregap detected for track 5 : 150 sectors
Pregap detected for track 6 : 150 sectors
Pregap detected for track 7 : 150 sectors
Pregap detected for track 8 : 150 sectors
Pregap detected for track 9 : 150 sectors
Pregap detected for track 10 : 150 sectors
Pregap detected for track 11 : 150 sectors
Pregap detected for track 12 : 150 sectors
Pregap detected for track 13 : 150 sectors
Pregap detected for track 14 : 150 sectors
Pregap detected for track 15 : 150 sectors

Track 6 is even weirder, it appears to have several seconds of track 5 at the start, then the pregap, then track 6...

The first two appear to be an issue with rubyripper, and the others seems to be like you said, the drive isn't staying true to it's +6 offset during track changes, I'll give those other drives a go, and find out if there's a way to get rubyripper to detect all track pregaps.

Edit: I converted track 6 of both versions to flac and played them, the broken track 6 does indeed have ~6 seconds of the end of track 5, then pregap, then track 6 at the start

Go to forum: General discussion

17 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

Of course, if there are no many differences, you could match the files and compare.

Alright, so I now have repaired versions of those tracks (which now match the DB), but how should i go about comparing them? what information could i find out that can help me?

In anycase, I'm going to sleep for now (3:34AM here!), in the morning I will try out those other cd-rom drives to see what results I get. I may also try PerfectRip in a windows VM.

Thanks for the help thus far, much appreciated.

Go to forum: General discussion

18 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

drives with -24 offset correction are interesting to dump the last track of many discs if combined offset is negative

Very interesting

As for the par2 files, I have used quickpar just once before, quite recently. I presume you want me to attempt to repair the dumps I have using your files, then post a diff of the original and repaired files?

In anycase, I need to dump those tracks again, won't take too long.

Go to forum: General discussion

19 Reply by MikuroK

(41 replies, posted in General discussion)

pablogm123 wrote:

Perhaps, you software/drive cannot overread into pregap or lead-out, and your dump is missing a few of bytes replaced by zeroes. If combined offset is negative, you could miss data of first audio track (at the beginning), if positive of last audio track (at the end). Do you own the very same versions from the DB? Which tracks of Ridge Racer can you match?

By now, forget the fff utility.

Rollcage is -647 (so -641 was used in rubyripper, on the slimtype (+6)), the other two are +2 (+8 used in rr)
As far as I can tell, the versions are identical, all have matching data tracks, region, serial, and edition all match

As for Ridge Racer, out of 14 tracks, i have matching results for tracks 1,4,5,8,9,10,11,12,14 (unmatching 2,3,6,7,13)

the three discs are;
http://redump.org/disc/922/
http://redump.org/disc/989/
http://redump.org/disc/1178/
rollcage is not one i'm concentrating on right now, as it only has one dump in the DB, so it itself could be inaccurate.

Other drives I've found lying around are,
LG Electronics - CD-ROM GCR-8521B     -24
COMPAQ - CRD-8322B     -24
LITE-ON - DVDRW SOHW-1213S     +12
Incase you happen to know anything about them.

Go to forum: General discussion

20 Reply by MikuroK

(41 replies, posted in General discussion)

jamjam wrote:

if the offset it incorrect, how is it i'm able to get some correct tracks?

Are the matching tracks just filled with zeroes? It's the only likely way an incorrect offset could yield matching tracks so it's worth checking.

no, they are tracks containing music, i'm aware of blank tracks, as they were the only ones i could dump accurately before learning about offset compensation.
For example, Rollcage tracks 4 through 15 match those in the redump DB, leaving only the first two (2,3) and the last one (16) audio tracks incorrect (data (1) is also matched), this was dumped from the slimtype drive.

@pablogm123
Seems perfectrip can't find my disc drive when run in wine, it's probably trying to use Aspi. isobuster works in wine, because it can be set to SPTI, which wine supports.

>others pure audio extractors aren't affected.
fyi, rubyripper only works on audio data, it doesn't support data track ripping. I use cdrdao to dump the data track (and split the result with bchunk), which works well for me so far.

I'm not sure what I'm expected to use fff.exe for...

Go to forum: General discussion

21 Reply by MikuroK

(41 replies, posted in General discussion)

cd's are not a very simple format, are they?

i tried the qpxtool on both drives with my MDK disc, results are attached.
if it's any use, the firmware on my lite-on drive is "US0N"

I'm looking into PR (PerfectRip, I presume?) now.

if the offset it incorrect, how is it i'm able to get some correct tracks?

Go to forum: General discussion

22 Reply by MikuroK

(41 replies, posted in General discussion)

usurper wrote:

If no track matches, you prolly not using the correct offset.
Does you drive support overreading? if not, this could be an issue as well.
If you provide additional information (what drive you use) and also your EAC logs, we could provide help.

I don't have windows installed, nor do I want to install it. I am using isobuster in wine to find offsets until i find a native tool to do this.
i can provide rubyripper logs, though

pablogm123 wrote:

And, are you sure that Rubyripper is detecting the correct gaps, and gaps are appended to next track?

yes, the detected pregaps were always the same as in the database, so were the filesizes, gaps are prepended to the current track, but this can't be an issue, as i mentioned some tracks *are* matching, if the pregap method was wrong, none of them would match.

the drives i'm using right now are; Slimtype - eSAU208 4 (+6), and LITE-ON - DVDRW SOHW-812S (+12), i have access to a couple others, if needed

I'll check out that tool, looks like my lite-on drive is on the supported drives list for it, maybe i should use that drive more (i'm using the slimtype mainly atm)

Go to forum: General discussion

23 Topic by MikuroK

(41 replies, posted in General discussion)

I'm getting erratic results trying to dump games with audio tracks, i feel like i'm still missing something... just now i'm trying to dump the games MDK, Ridge Racer, and Rollcage (PSX).

ridge racer and rollcage give matching tracks to the ones listed in the database, but not all of them match, mdk doesn't match with any tracks listed.

all disks are in pretty good shape, with only ridge racer causing retries in my dumper (and the tracks that did give warnings, happened to match the DB)

I'm using rubyripper in linux, with the correct combined offset for each disc (else i would get no matches at all), and i have it set to copy/test each track at least 3 times

i've even tried using another cd reader, with a different read offset, my results are all the same, but some tracks still don't match the DB

let me know if you need more details (hash listings?), and thanks for your time

Go to forum: General discussion