Search options (Page 5 of 12)

If you are lucky (fictitious example) that file is using just 240 bytes of the last allocated sector (rest of user data is just slack), so for mode 2 form 1 sectors you still have available 1808 bytes of slack you can use freely once altered the file size in the file record, easy to spot seeing the last sector of that file in the IsoBuster's sector viewer. The ideal situation would be that file is the last one in the file system, so you can increase freely and easily the size (increasing by a few of sectors the size of file system according to the PVD if needed). Check the starting/endings LBAs of files by IsoBuster to determinate if you are in luck. And for seaching the file record, search for [Original file name];1 . Reallocating the file to a new LBA would be a no go path in my opinion, you don't know if the starting LBA of that file expected by game is hard coded in game code and whatnot, or just checks starting LBA according to file system.

Observe those values are actually duplicated, first copy in Little Endian format, second copy in Big Endian format. So you have to modify both.

Little Endian: 0C FC 03 00
Big Endian: 00 03 FC 0C

Once modified anything, run CDmage, scan for errors and REBUILD fields so that EDC/ECC data matches the new user data.

Disclaimer: never tried this by myself, I purchase retro games just for the RedBook sountracks, so I haven't found so far any need of altering a data track.

To try to read the very beggining of the lead-in.

http://www.cdtool.pwp.blueyonder.co.uk/instructions.htm

http://club.myce.com/showthread.php?p=1067119

Anyway, I have tried this a few of times and I got only strange mechanical noises, the drive remains busy for a few of minutes and whatnot, so assume that this is a no go (or at least works with only very few discs/drives combinations) and unhealthy for the drive.

/p option doesn't work properly, Plextor drives can rip only the -75, -1 range of the first pregap directly. It's somewhat hard to explain the correct method to dump properly the first pregap when this one contains actual audio data (the miniCD Audio disc bundled with Tenbu MegaCD Special, for example), but would something like this.

-Read the -5000,-76 range, D8 command of couse. When reach more or less the -1000 LBA will report many read errors, it's normal and expected.

-A part of the lead-in, the entire first pregap and a piece of the first track, index 1, is dumped.

-Then use the first sectors of the normal dump to search them in the dumped file, find the portion which matches those first sectors and extract the previous 352800 bytes into a separated file.

-The subcode is easy, just extract into a separarated file the frames with 00:00:00 - 00:01:74 AMSF.

http://www.mediafire.com/?470d0r269wg6bce

I have uploaded a sample, the entire minidisc and the pregap extracted as I have proposed via the audio option.

Then, I have hashed the first 75 sectors of the first track and these ones are the results. Program used is parthash, much easier than cutting the dump and whatnot:
http://forum.redump.org/topic/13085/

D:\MiniCD\Main dump>parthash "MiniCD (Track 1).bin" 176400
#        Size   CRC-32                        MD5/SHA-1
1      176400 fa5fa23f 4e9bff8a8ab29fafb6252977de6b11ea
                714a04d835419264528b0327c143de4267e3d961
2    39588864 e0c9e590 4083df206ba8ab18864aa27590ac346c
                dc47b01492f14f26b60bccd4de635d016a2b239d

Then I run the findcrcs.exe program by V. in the lead-in+first pregap+a piece of first track dump and these are the results:

D:\MiniCD\Pregap>findcrcs Pregap.bin 176400 FA5FA23F
4290048  fa5fa23f  4e9bff8a8ab29fafb6252977de6b11ea

Thus 4290048 is the starting point of the main dump, so I have to extract 3937248-4290047 range into a separated file to have the actual pregap ripped once and for all. The subcode is easy, just delete everything except the range with AMSF 00:00:00 - 00:01:74.

findcrcs.exe program is here, including source code.

http://forum.redump.org/topic/12450/

With these suggestions, perhaps you can implement a proper routine to extract properly the first pregap of these discs.

And it would be cool to implement another routine to extract the lead-out of certain discs which contains audio data in the lead-out. My Alanis Morissette - Jagged Little Pill [UK(9362-459012)], as far you remember you purchased this one to perform certain tests related to the slowness when ripping discs with R-W filled with 0xff, contains data in the actual lead-out, so could be useful to implement an option to rip into a separated file the first 100 sectors of the lead-out, applying either the offset correction autodetected by D8 (if disc contains a data track, Heavy nova for MCD for example), the standard one of AccurateRip or the overriden by the /a parameter.

DIC won't create the actual processed and splitted dump. For any reason, the subcode data gets messed and therefore DIC will fail to process the scrambled dump.

Files (except the scrambled dump itself), the expected and fully clean subcode extracted by subdump to compare against and screenshots.

http://www.mediafire.com/?7lcpwnoadeg5g5k

These things happen when discs contain these weird pregaps. Or better said, these weird no pregaps in the data-audio transitions. I guess that you will need the old px_d8 (the one which only prints the requested sector) and run something like this:

pxd8.exe g: 5995 1 > 5995.txt

And post the 5995.txt file.

Lite-On LTD-165H is the classic suggested drive by the Yursoft's guide.

Yes, that site is down currently.

Edit: currently online. Just in case the website goes down newly, I have mirrored the four files:

https://www.dropbox.com/sh/k5tlk3e426u0lwu/-wmri4wOce

Fixed:

https://www.dropbox.com/s/j9uzsc4g42746 … %20disk.7z

Expected size and same hashes than HxD and Roadkil's Disk Image.

As far I know, you can extract the PS3 discs using a normal BD reader/writer (MediaTek based, +6 in AccurateRip list) for PC using IsoBuster. Then that special PCB and a spare BD-ROM of a PS3 remarried (you cannot reuse anymore this BD-ROM in any PS3) to extract the metadata.

Read this thread.

http://forum.redump.org/topic/13284/add … -8xredump/

Anyway, just be patient until Enker can see this thread and answer your questions.

STORAGE ADAPTER DESCRIPTOR DATA
                  Version: 00000020
                TotalSize: 00000020
    MaximumTransferLength: 00010000 (bytes)
     MaximumPhysicalPages: 00000011
            AlignmentMask: 00000000
           AdapterUsesPio: False
         AdapterScansDown: False
          CommandQueueing: False
      AcceleratedTransfer: False
          BusMajorVersion: 0002
          BusMinorVersion: 0000

Mine is actually a TU drive, the same drive in a USB 2.0 enclosure, NEC chipset perhaps. Of course latest official firmware.

And I have absolutely no software which installs filter drivers (lower and upper filters) and no SPTD layer. I am fully against that kind of things, so no CloneCD, Daemon Tools... for me in my main OS (if I eventually need them, I run them from a secondary OS installed into an eSATA hard disk). This very likely has something to do with the 8 KB transfers for USB/IEEE-1394 drives suggestion I suggested a time ago.

PX-755SA via JMB363 (a PCIe card, latest jraid.sys driver) works nicely.

I will do so, Enker.

And http://redump.org/disc/11382/ should be corrected to «PlayStation the Best for Family», because sarami reported that edition and seeing this eBay article he is right.

http://www.ebay.com/itm/231108130138