Redump Forum

Btw, -x 1 appears to be much better for Plextor.. it no longer makes any sounds and the reading cycle is only 2 seconds.. although I still don't understand why the last parameter doesn't work.

Just so this is clear: -016,32 means that 16 sectors are read with the read command, and 32 are read from buffer (so with this command, the filesize should increase by ~64kb everytime instead of the normal 32?)? If so, then I don't see why it works fine in readbuf_tool if you read e.g. 206400 bytes from the buffer and why not here with 100 sectors.. maybe there's a bug? Also, since Plextor buffer holds up to 624 sectors, is it possible to raise the limit from 100 to for instance 1000?

Tests with a normal DVD:

1. 'friidump -d d: -c 0 -x 1 -T 3 -0 -r test.iso' reads a normal dvd at ~650 mb/s on Plextor! So looks like you're right and Plextor needs a different approach for GC.
2. 'friidump -d e: -c 1 -x 1 -T 3 -0 -r test.iso' works fine on Samsung and normal DVD, although contents are scrambled (like in Truong's tool).

So, normal DVD's are working fine, but gamecube discs act entirely different on Plextor (with and without swapping) and Samsung (only tested without swapping).. iR0b0t is having the same issues, so I guess that for now, only lite-on drives offer results that are comparable to LG's?

Just so this is clear: -016,32 means that 16 sectors are read with the read command, and 32 are read from buffer

yes

(so with this command, the filesize should increase by ~64kb everytime instead of the normal 32?)? If so, then I don't see why it works fine in readbuf_tool if you read e.g. 206400 bytes from the buffer and why not here with 100 sectors.. maybe there's a bug? Also, since Plextor buffer holds up to 624 sectors, is it possible to raise the limit from 100 to for instance 1000?

readbuf_tool reads data in 64kb chunks, if it's more than that, it would loop until criteria is met
friidump does the same, actually about everything i know does
(e.g. CD tools would usually read 26 sectors at a time which is 26*2448=63648 )
as this is the size that all devices should support, larger than that does not have to work and often it doesn't
drive is not only thing responsible for this limit, ther's also controller, drivers and such
for example my IDE controller is weird - picky on data alignment
and older PC i have in other room wouldn't read buffer at all from this very same LH-18A1H

DVD drives would return either 2064 or 2384 byte RAW sectors
sectors are grouped in blocks by 16
all this is taken into account when doing reads with those methods, so that's why i said it's non linear
100 sectors, it's more than 5 blocks, that best Hitachi method has
friidump's author had ~1250 MB/h with it and some guys would get as much as 2500 MB/h
Lite-On would do about ~1100 on 27 sector requests (27*2384=64368 - about full page); ~2000 on PC DVDs
so further it wouldn't matter really, it would mean drive has to fill this amount of cache inbetween reads,
while calculations are done - it's very unrealistic

dumping fails because there are numerous checks done on data sequence and integrity
therer's likely incorrect content returned from cache, e.g. garbage or sectors from previous reads

1. 'friidump -d d: -c 0 -x 1 -T 3 -0 -r test.iso' reads a normal dvd at ~650 mb/s on Plextor! So looks like you're right and Plextor needs a different approach for GC.
2. 'friidump -d e: -c 1 -x 1 -T 3 -0 -r test.iso' works fine on Samsung and normal DVD, although contents are scrambled (like in Truong's tool).

So, normal DVD's are working fine, but gamecube discs act entirely different on Plextor (with and without swapping) and Samsung (only tested without swapping).. iR0b0t is having the same issues, so I guess that for now, only lite-on drives offer results that are comparable to LG's?

yeah, we have to disable those error corrections
i'll send you a program later tonight to try some things out, ok?

Now that we have RAW DVD dumping capability, I will be doing some experiments.

I've already tried to compare the dvdtoimg output of a DVD movie with friidump in 2048 mode.. friidump aborts at the layer change.. and another difference is that the friidump output has an offset difference of -6 bytes.

@themabus, is there anything that could explain this offset difference? The dvdtoimg offset seems correct.

This offset difference is used to reallign GC (and I think also Wii) disc frame layout (this as long as I know is the GC protection). It has to be added an option to avoid this shift for non-Nintendo dvds.

http://debugmo.de/?p=96

A GOD has a different Data Frame layout. Instead of not using the magic 6 bytes, they shifted the whole user data 6 bytes to the front. That means that there is no scrambling applied to the first 6 bytes of each sector. Each user sector is still 2048 bytes; it’s just that the last 6 bytes (before the EDC) are unused, not those in front of the user data.

yes, i haven't fixed this yet. and also Plextor's RAW output would be different from other drives.
author refers to scrambled data + header & EDC as RAW sectors,
and as i understand it most people do so, but Plextor doesn't provide scrambled output
and either way i don't think this format would be too useful.
so should i instead set this mode to unscrambled+header+EDC for rest of the drives, alike to Plextor?

ok, 0.5.2:
- Corrected handling of standard DVDs
  (type should be forced to 3, when dumping or unscrambling).
- Better response to 'speed' parameter.
- Uniform raw output for all devices: unscrambled data + headers.
- Slight performance increase (~1650 MB/h on LH-18A1H).
- Added LH-18A1P, LH-20A1H, LH-20A1P to list of supported devices.

so raw output now also depends on disc type, i.e. --type (-T) parameter
default is Nintendo layout, but for regular DVDs always should be forced to 3

and i couldn't actually test dual-layer DVDs, because of lack of free space

FriiDump 0.5.3 (src) Linux build
- Fixed failing after 1st DL media layer with non-Hitachi methods.
- Fixed still hashing with 'nohash' parameter when resuming.
- Fixed resuming larger files (~4 GB).
- Fixed unscrambling larger files.
- Faster file unscrambling.
- Slight modifications to methods;
  possible performance increase with Hitachi based devices.
- Restructured methods and added some new ones.
- Added layer break information.
- Added current position output when error occurs.
- Added SH-D162A, SH-D162B, SH-D162C & SH-D162D as supported.

Lite-On going as fast as 5400 MB/h with ordinary DVDs
Hitachi-LG expected to be as fast as RawDump and i  fixed up everything i could find wrong
so likely won't be doing any updates to this any longer unless new drives need to be added

included with it is program that could be used to determine READ BUFFER command parameters
for yet unsupported drives
so if you do have one of those and have any luck with it, please report your results here.

Just had a go at dumping https://redump.info/disc/11512/ with FriiDump 0.5.3


settings: friidump -d e: -c 1 -x 1 -T 3 -0 -i capcom.iso'

drive: SH-D162D

the friidump-dump matched the database.

.

this is a lot faster cmd.line, on my system...Athlon 64bit 4 ghz / 4gb ddr ram / PCIE / Vista 64-Bit
friidump -d v: -c 1 -x 1 -T 3 -0=[16,32] -i Steamboy.iso

1695 Mb/h, no swap, normal dvd-video, it's an un-copyable 1/3 though, just seeing what raw dumping can do. On one system.

.

Other system using same cmd.line, which is usually better/faster 4 ghz pentium core duo / 4gb ddr2 ram / PCIE / XP 32-Bit

friidump -d f: -c 1 -x 1 -T 3 -0=[16,32] -i Tekkonkinkreet.iso

1345 Mb/h, no swap, normal dvd-video, it's an un-copyable 2/3 though, just seeing what raw dumping can do. On one system.


.

What speeds did you get on the samsung? and did you swap?

I haven't tested swapping with samsung, so hoping to hear from you.

Both dumps gave up at 3%, luckily I managed to get my PC shutdown, without crashing.

Any news on gamecube, on the SH-D162D, I still keep meaning to get one of the LG's.