EAC doesn't know about data tracks, so it enters in the cuesheet as:
FILE "<Filename>.iso" BINARY
  TRACK 01 MODEx/2xxx

You need to enter the correct filename and mode/sector size for the game. For PSX games this is always MODE2/2352, but otherwise make a cuesheet in ISOBuster and get the correct info from there.

In your example, replace "<Filename>.iso" with "Track 01.iso"

EAC also assumes you're going to be dumping WAV files, so we need to edit the cuesheet to reflect bin BINARY files. If you're using a good text editor like Notepad++
replace: .wav" WAVE
with: .bin" BINARY

Perhaps you've run into this problem?

53

(21 replies, posted in General discussion)

tossEAC wrote:

Any one know of any actuall programs that can split a 100mb or above into seperate 1 byte files numerically ordered

I really wouldn't suggest you do this. You would make that file 100MB file take up anywhere from 200GB to TBs. Explorer freezes up with tens of thousands, I'd be surprised if the OS didn't die in the tens of millions.

As r09 & amarok said, it is pretty much impossible to cut down random data.

I get what your idea is, to group all the same bytes together and compress them by describing them as a contiguous sequence. This isn't far from a real concept (RLE), but it doesn't work for bytes that aren't already grouped together, since it would take more than one byte to store the relative positions.

This is a byte:
o

If this byte was in a 7GB file, I'd have to name it something like this:
7421251637

This filename alone is 10 bytes (5 in hex).

There is a common way to store information about a large amount of data in a small amount, the checksum we all know and love. The checksum, however, can't be used to regenerate the data. A CRC32 is four bytes in length, so it can have ~4.3 billion values. If we had just one more file than its max, we'd 100% for sure run into an instance where two unique files had the same checksum (known as a collision). In fact, there are programs that can do this intentionally.

user7 wrote:

might be a good idea to put this on youtube?

I'll find a free webhost to dump a flash player and the MP4 on.

Screen captures are very sensitive to scaling, so I think YouTube would make the text hard to read.

RiMMER wrote:

Does the link actually work for anyone? I can't download that video .. it redirects me here.

Strange. Maybe they block regions or something? It's been downloaded by 5 people.

I've added a streaming player on Google Sites. Try that.

Hopefully this will help:
Flash Stream
SpeedyShare Download

Correction: 14:56 should say "sector" instead of "track".
Include the disc write offset in your post (Garbage data (combined) offset - your drive's offset)

I hope that covers about anything you'll need to know. I went over dumping Playstation games with audio tracks, including some special situations and troubles you might run into. Because of that, it is very long, but hopefully it covers any potential troubles you might run into.

If you're dumping data-only, just right-click extract raw the track in ISOBuster on a couple drives and make sure the checksums match (with a tool like DAMN HashCalc).

Things I didn't make clear, though should be done:
Be sure to dump the data track multiple times, in multiple drives, and make sure all the checksums match after the psxt001z fix (with a tool like DAMN HashCalc).

Always use the combined offset (the one you find by counting lines of garbage) in EAC offset correction. To find the factory offset from the combined offset, do: combined offset - drive offset (look up your drive in this list). So a combined +669 in a +667 drive would be 669-667 = +2 factory write offset. You can only do this for data+audio discs without a Plextor.

Use psxt001z to check for anomalies. When running it with plain "psxt001z.exe track01.bin", it will tell you the expected total filesize of the image. If the sum of your data+audio track bin files don't match up, something is wrong.

56

(18 replies, posted in General discussion)

That's a "fun" EAC bug where 2 track data+audio discs will have bad gap detection. You can add the pregap manually, or dump the whole entire track manually with ISOBuster.

Anyways, here's what you can do to solve this:

The easy way:
Dump the disc as normal. The resulting track will be missing the pregap (since it was determined gapless).

The gap is probably two seconds. So what you'll want to do is use ISOBuster, right-click track 2 and go into the sector view. Subtract 149 from the sector counter in the box. Now hit the back arrow once (a total of 150) and you should see some garbage data followed by many 00s (This is the same process as the guide "Determining the (factory) write offset"). So, take the number of sectors there are from the start of the track to the garbage data (150 most of the time, or what you determined yourself) and multiply that by 2352.

Grab a hex editor (like XVI32). Now, edit>insert string. Click "Hex string" and type 00. Under "Insert <n> times" hit decimal and put the number you did earlier. We've now successfully added the missing pregap, so all should be well if no mistakes were made.

The hard way:
[ISOBuster completely manual, not really that hard once you're used to it.

First, we need to determine the pregap length. The gap is probably two seconds. So what you'll want to do is use ISOBuster, right-click track 2 and go into the sector view. Subtract 149 from the sector counter in the box. Now hit the back arrow once (a total of 150) and you should see some garbage data followed by many 00s (This is the same process as the guide "Determining the (factory) write offset").

So, take the number of sectors there are from the start of the track to the garbage data (150 most of the time, or what you determined yourself) and multiply that by 2352. Note this for later, denote as "gap length, bytes". You can also dump the disc with Slysoft CloneCD and run the resulting sub through Subcode analyzer to have the gap length automatically determined (in seconds).

Now, ISOBuster doesn't give us offset correction, so we will have to do that manually. Look at the sector with garbage data and determine the combined offset (as per the guide). Because the data is going to be pushed forward or backward, we have to dump an extra sector worth of data. So right-click the track and click extract from-to. The start sector depends on the combined offset. If your offset is <-588 or >588, you'll divide it by 588, round up (or down if negative offset) (-617 would be -2, +1566 would be +3, etc), and start dumping that many sectors early or late. Unless the offset is evenly divisible by 588, we will need to add +1 to the length.

In the unlikely event that the combined offset is evenly divisible by 588, we don't have to trim. Otherwise:
Let us pretend that we determined the combined offset to be +32 (+2 disc, +30 drive). What we'll do is open the Track 2 bin in a hex editor (such as XVI32). Now, because the offset is positive, the data will be pushed forward (if the offset was negative, it'd be pushed backward, so we subtract 2352 from offset*4 until we get a negative result. Convert to positive, and that's the 00 bytes to skip). There are 4 bytes in a sample, so the data is pushed forward 128 bytes in our example. Open the file so that the 1st byte is highlighted, and Address>Goto. Click decimal and "relative down". Set the number to our offset -1 (since we start at 1 and want to get to 128, we go down 127). Now some 00s should be skipped. Go to edit>delete to cursor. The extra bytes will be removed.

Now, edit>insert string. Click "Hex string" and type 00. Under "Insert <n> times" hit decimal and put the number as your previously noted gap length in bytes. Hit OK.

Now there's just one final step, and that is to remove the extra data from the end. Drag the scroll bar all the way to the bottom. The last byte should be highlighted. Take the number of bytes you deleted from the beginning (128, in our example) and subtract that from 2352 (2224, in our case). This is how many extra bytes remain from that "extra sector" we dumped in ISOBuster, which we have to remove. So, Address>Goto, decimal relative up, our number - 1 (2223 in our ex). Now choose edit delete from cursor. This will remove the garbage data from the end of the track.

So, the steps we've done: Dumped the data track with an extra sector to account for offset. Trimmed the extra sector from the beginning and end of the track, correcting the offset in the process. Inserted the pregap.

It's worth noting that since we're dumping the last track, it would be ideal if the combined offset was negative

Now, not in your case, but in the event that the track we are dumping isn't the last, we have to delete the next track's gap from the end of the file. In a 2s 2s 2s common disc, this would involve deleting 352,800 bytes from the end in addition to the bit from the extra sector.

57

(18 replies, posted in General discussion)

If you launch the bat (on XP 32-bit or earlier) the filesize of Track 01.bin should decrease by ~345KB (F5 to refresh folder). If you've run that command multiple times, you'll have to dump the track again since the track will be damaged.

resize.com doesn't pause when it's done, so the cmd window will disappear right after it shows up. If you want verification that the command has run successfully, open a cmd prompt and navigate to the folder, so the window doesn't disappear after it has finished.
Alternatively, you can pipe the output to a txt file in your BAT, like:
RESIZE -r -352800 "Track 01.bin" > resize.log

58

(18 replies, posted in General discussion)

The resize utility trims the padding from the end of the track, which is present on multi-track PSX games.

So what you do is place resize.com in the same folder as the Track 1 bin file.
Open a command prompt and cd to the folder where the bin and .com file are.
Then run the command: RESIZE -r -352800 "Track 01.bin"

The number is the length of track 2's pregap in bytes. For two seconds (the most common) this is 352,800 bytes.

This trims the unnecessary padding from the end of the data track. Now you can repair the track with psxt001z by issuing the following command:
psxt001z.exe --fix "Track 01.bin"

psxt001z.exe should only correct errors in 1 sector, that being the last. Sometimes no errors are detected.

Thanks much. I haven't done this before.

I checked the headers that were previously nulled and they were intact in this read.

I don't seem to get the luxury of error detection in this raw read mode, so it didn't perfectly match up, but at least I know now that the Plextor was actually damaging the data rather than "getting 350 good sectors".

Thanks for the response. I'm grateful for your help, as this had me utterly perplexed.

cdtoimg seems to be outputting garbage data, even reading at 1x :\

How can I read from the buffer? I can try swapping later, but I'd prefer something that didn't involve manually ejecting the tray.

My motherboard is coincidentally an ASUS P5Q Pro, but I'm using the drive through an IDE>USB interface.

So, I'm trying to dump the Interactive CD Sampler Pack Volume 2.

I dumped the disc on my GH20NS15 and LH-20A1H with matching results. I also matched this to an image I found on the Internet. The disc has 1,916 sector errors, all in the ASOCCER speech files, like so:
http://i48.tinypic.com/2cxeo9z_th.png

So far so good. Matching in two drives + an internet source = good dump, right?

The problem I have is that my Plextor PX-760A gives a different result. More specifically, it dumps with fewer sector errors. When I dumped twice yesterday (without recycling), the resulting dumps had only 1,556 sector errors and matched. Today I dumped the disc twice again in the Plextor, recycling the drive each time, and came up with non-matching dumps with 1,557 sector errors.

So my question is, what can I do from here? If I didn't have the Plextor to begin with, I'd have reasonable grounds to call a good dump. The Plextor isn't giving off consistent results, making it not a reliable indicator, but it still stands that it's getting 350 good sectors that my other drives can't.

GH20NS15 (1,916 sector errors):
SHA-160     : 63F828EC7BB0A8317E10E934D434560475DBE8BB
MD5         : ACFA22E8B9018B16B3BB82009A3EC886
CRC-32      : 1A138846

LH-20A1H (1,916 sector errors):
SHA-160     : 63F828EC7BB0A8317E10E934D434560475DBE8BB
MD5         : ACFA22E8B9018B16B3BB82009A3EC886
CRC-32      : 1A138846

Web-sourced track 1 with last sector fixed with psxt001z.exe (1,916 sector errors):
SHA-160     : 63F828EC7BB0A8317E10E934D434560475DBE8BB
MD5         : ACFA22E8B9018B16B3BB82009A3EC886
CRC-32      : 1A138846

Plextor PX-760A two dumps with no recycle inbetween (1,556 sector errors):
SHA-160     : 4450E22CA8739BC713A3C5C39F7F50024D7063F0
MD5         : AC9EF9042F722C909398C803283EAA40
CRC-32      : E7D8181A

Plextor PX-760A dump 1/2 with recycle (1,557 sector errors):
SHA-160     : 1A533DAE98B15B2168911949463FB94ECFBE4E44
MD5         : EB7CD639F58C212B5B4B28A93B4F4D79
CRC-32      : C6F9D9FB

Plextor PX-760 dump 2/2 with recycle (1,557 sector errors):
SHA-160     : 14D652DB6272DA981B4463971F8AEAB9E9244EFD
MD5         : 94D5819ACE0E280B58A32EF4486117F5
CRC-32      : F34DA670

For the sake of curiosity, I dumped a length of sectors which differed in the two drives and looked at them in HexCmp2. The only differences between the two drives is that the GH+LH have 5 bytes of data in each sector, while the dumps from the PX do not, like so:
http://i46.tinypic.com/2wdzl8n_th.png

This 5 byte string goes like this:
01 0C 64 04 01
01 0D 64 04 01
...
01 1F 64 04 01

After which it resets to 0C and starts again.

Funny you should mention that. I only had the crash after I installed Photoshop CS4, but at the same time I only tried ripping to my D: drive after said installation. I did not, however, install Adobe Drive. Strange...

Update: Right-click properties the shortcut to EAC and click the compatibility tab. Check disable visual themes and you'll be good to go unless you have Adobe Drive installed. Read deletable_man's 2nd post.

Open regedit and explore the following area:
HKEY_CURRENT_USER\Software\AWSoftware\EAC

Backup your settings by exporting AWSoftware before doing any editing. Change any non C: locations to locations on C:.

I'm not sure whether this bug is specific to non-C: drives, non-system drives, or drives other than the one EAC is installed to. Try using different different drive letters if necessary.

If nothing seems to work, delete the entire AWSoftware entry (after backing it up, of course) to start EAC fresh and try to get it to rip and log with no crashes. After you've got it figured out, configure as per the guide once again. You might also want to backup your working settings from the registry, in case you accidentally make it insta-crash again.

Hope that helps. Be sure to report back your results.

Update: Right-click properties the shortcut to EAC and click the compatibility tab. Check disable visual themes and you'll be good to go unless you have Adobe Drive installed. Read deletable_man's 2nd post.

Pardon the bump, but I thought I might post this in case it helps someone else in the future.

I have just had this happen to me too. It happened when I tried to change my save directory to (with "ask me every time" enabled) a drive other than C:. This doesn't happen when "browse folders" is expanded though, only when in the smaller-type dialog. It also doesn't happen on Windows XP.

EAC must not like the small save-as dialog in Vista/Win7 in conjuction with multiple drives?

In a case like yours where it crashes instantly (setting says the default dir is the last used folder), try setting a static path to a local drive for a single rip, then changing back so it forgets your path. After that, you should be able to rip to a directory on a local drive. I fear that if you use the expanded "browse folders" to save to a problematic folder, it'll remember that and insta-crash the next time. If your local drive doesn't have enough space, might be best to use a static path.

65

(2 replies, posted in General discussion)

I don't understand why Geocities removed all their pages anyways, since they still run the service in Japan.

I've been thinking of picking up some PICs to make a stealth and non-stealth setup to play or test games for anti-mod on a PSOne mini. Any recommendations on firmwares?

I was hoping to be able to install a switch on the voltage wires to toggle between stealth and non-stealth chips, but it seems some chips have you install a wire between two points on the board, so I don't know if I could install two different chips in such a situation. Edit: Haha, I'm dumb. DPDT switch wink

Firmware recommendations would be much appreciated.

P.S. I asked iR0b0t before posting this, so hopefully it is okay.

Support for 16-bit stuff was removed after XP, so Vista and Win7 won't support it. The guide should probably be updated to reflect this, so people aren't scared off when something doesn't go right.

I made a brief step-by-step tutorial for manually doing this in a hex editor in another thread.

You can also just extract a range in ISOBuster like iR0b0t said. To clarify his statement, Just right-click on the track and hit extract from-to. ISOBuster will fill in all the details for the selected track by default, so just reduce the Length (LBA) box's value by the sector equivalent of Track 2's pregap (usually 150 sectors, 2 seconds). [I wish I had thought of this, it's even easier than using resize.com, thanks iR0b0t!]

Ah, okay then. It had me worried with Revolution X that the "corrected sectors" were null.

Hello all.

I've ran into this on a couple of discs and I seek advice. At the end of the track's read, one of the rows of EAC's error correction will start to light up. The resulting track has a quality >= 99.7%.

One disk I ran into this I know is a good dump, as the track matches one in the db (Battle Arena Toshinden Remix, Saturn, Track 10).

I have two Playstation games at the moment that do this as well. Agile Warrior F-IIIX and Revolution X. Agile Warrior does this on Track 9, and Revolution X does it on 5, 7, and 11. With these two discs, I have no db entries to compare my dump to.

How should I proceed? I have a PX-760A coming in the mail, so I can try some plextor-specific tools. (Need it to dump the last track on that pesky +588 saturn game cool )

Verified Revolution X
-----------------------------------
Edit: Matched a web dump to my Revolution X Track 5 with some sample shifting, so this is truly the way the disc is. I did not expect this at all. When originally checking my dumps, since the tracks were signed RIFF WAVE, I determined the file length based on the header and extracted a proper WAV. The result was a file that had blank samples at the end, which didn't happen with the 100% tracks. The disc must have just been made badly :S

I expect I'll find the same with tracks 7 and 11, but I'll check.

Yep, all three tracks match after sample shifting.
-----------------------------------

I'll have to see if I can find something to match up to Agile Warrior. What are some general rules of thumb on this though?

Verified Agile Warrior
-----------------------------------
Web version only had one data track, but I was able to match the start and end of the track. The file didn't match exactly, as the web version had its data stored in a data track vs an audio track, but I was able to align the ends of each, verifying that my end sectors are good.
-----------------------------------