Some info on 2064 bytes/sector RAW DVD dumping:

Apparently, what LG drives do is, they read the buffer of the drive in order to get the RAW contents of a DVD. There are 2 tools for LG drives that can do this and one tool that works on Plextor drives (and also on several other drives?)!

Here's a tool by Truong that you can use to test the command on Plextor (and other?) drives. First, you have to read a sector the normal way (e.g. with isobuster), and then you can use this tool to save the buffer: http://vigi.dremora.com/rawdvd/readbuf_dump.zip.

If you have an LG drive, try one of the following tools instead (and use the different program name in the example):
Newer drives: http://vigi.dremora.com/rawdvd/ren_hit_lg_dump.zip
Older drives: http://vigi.dremora.com/rawdvd/hit_dump.zip

Usage:

readbuf_dump <drive letter> <output file> <start offset> <len>

Examples:

'readbuf_dump d mem.bin 0 235200' dumps the first 100 CD (2352-byte) sectors from the D: drive buffer
'readbuf_dump d mem.bin 0 206400' dumps the first 100 DVD (2064-byte) sectors from the D: drive buffer

Unfortunately you can't use this tool to dump complete cd's, so we're working on a solution for that!

Many thanks again to Truong for the tools..

ps. the 'Read Buffer' command for Plextor etc. drives is documented here: http://www.13thmonkey.org/documentation … andset.pdf  (page 164 of the internal document).

officially unofficial friidump 0.5.0
http://www.mediafire.com/?mzmyntwmowy

- Regions: Italy, France, Germany, Spain, Australia, PAL-X, PAL-Y.
- Updated publisher list from http://wiitdb.com/Company/HomePage
- Included GDR8082N & GDR8161B as supported Hitachi drives.
- Lite-On, Renesas & vanilla memory buffer access commands.
- Shifted methods 1..4 to 0..3 and added new ones 4..6
  Associated known drives with default methods.
- Additional commandline parameters:
  stop, speed, command, type, size

should work with most Lite-Ons, maybe other MediaTek based drives (Asus, Dell, Sony, etc.)
though ~1100 MB/h was most i could get out of mine
and it did need swapping

first thing to try to see whether it works on your drive
would be some PC DVDs - try it with all commands & method 0

if program can get seeds - buffer reading works
so you can proceed with testing methods 4->5->6->1->2->3

if PC DVD works and GC/Wii does not, your drive needs swapping

if you are going to swap DVDs, be sure to use '--type' or '--size' parameter


please report your results here

edit:
btw you can use CTRL+C to halt program's execution if something goes wrong
or it takes too long, etc.

Hi,

many thanks for this.. gamecube dumping is working on Plextor now (with command 0)! is there any way to speed up dumping? trying different methods now, but it seems to be stuck at 28.47 mb/h (~32 kb each cycle, which takes maybe 3 seconds)!.. maybe you can add a new vanilla method that reads as many sectors as requested at a time? because I think the Plextor caches much more sectors (>500) with each read, so this could speed up the dumping dramatically, at least for command 0 drives.. (with 500 sectors each cycle it would be at least 30 times faster than it is now) smile

Also, it seems like the raw output for normal dvd's is not correct.. would it be possible to support normal DVD's also?  cool

oh, great, i didn't think Plextor would.

yeah, we could definitely try this.

it's strange though that method 4 does not work, it's the same as 0,
but with streaming parameter set, so less error correction would be done.

maybe we could find something else, that works with Plextor,
like there are some parameters, that control error correction, but Lite-On wouldn't allow to change those,
maybe Plextor does.

i'll check on raw output, didn't test it to be honest, thank you for this.

edit:
and actually i forgot to add command for Samsung...

ok, i'll fix those things and then we could try to get more performance out of Plextor and Samsung (if it works)
with some specific methods.

btw, does Plextor work without swapping?

Actually, the Plextor DOES work with lite-on methods 4-6, but speed appears to be the same as method 0.

And I just tried, it does work without swapping! But you have to use stop command first. Samsung might also work then, but we'll need the new command smile Maybe swapping isn't needed after all then.

Looking forward to testing larger cycles and the samsung drive.. wink

edit: I just tested my plextor buffer capacity and it's around 624 sectors for DVD's, so 500 or 600 should be a safe value, although a parameter would be ideal (different drives can have different limits).

- Plextor, worked for me too, with and without swapping, when dumping without swapping i had to force the disc type, otherwise the drive freezes and needs an os restart !

- Lite-On, didn't work, it stuck on disc seeds retrieving procedure, and it has never finished retrieving when i tried.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

ok, added parameters, added Samsung's command as 'vanilla 2384'
but it isn't currently associated with any drives and has to be selected manually
restricted Lite-On to that single tested model
and some fixes here and there

http://www.mediafire.com/?zthygznudnt

raw output works for me though, but iso output for non Nintendo DVDs would be incorrect
i'll either have to add regular descrambling algorithm
or remove this option sometime later, now for testing it's good

edit:
Lite-On's methods are now joined in single one - method1
method2 might work faster with Plextors, it's as 1 but without cache flushing

syntax for methods with parameters is --method0=16,16 or in short form -016,16

first value is how many sectors to read from DVD, so smaller might produce faster results
2nd value - nr. of sectors to fetch from cache, effect from changing this won't be linear
but generally it's better to keep it close to multiple of 16

Thanks! Some feedback while I continue to test:

- Method 2 isn't working on Plextor
- Command 1 isn't working on my SH-162D.. but unlike other commands, it doesn't abort retreiving disc seeds right away (none of the commands cause any reading.. maybe swap disc is a must after all?)
- I'm unable to get any noticeable speed increase on Plextor (for instance, this parameter: 'friidump -d d: -c 0 -T 0 -i test.iso --method0=16,512' is about the same speed as before sad So maybe a bug with the parameters? Requested sectors and Expected sectors stays at 16 for every parameter that I tried (except when I do 16,64 but then it fails at retrieving disc seeds).

oh yes, they're limited to 100, so 512 resets to default value
but if 64 fails, it's too much already
i guess we'll have to to find something special for Plextor

does Samsung work with regular DVDs?

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.

My patch requests thread
--------------------------------

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.

18 (edited by tossEAC 2010-03-25 14:29:08)

Just had a go at dumping http://redump.org/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.


.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

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.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

Just had another succesfull go at dumping http://redump.org/disc/11512/ with FriiDump 0.5.3


friidump -d f: -c 1 -x 8 -T 3 -S 237325 -6=[8,48] -i capcom.iso

drive: SH-D162D

the friidump-dump matched the database.

The speed on the P4 Duo ended up @ 2515 MB/h when it finished

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

Well.. now you said it.. it's a normal dvd-video.. so that's why it's so fast.. I even doubt if you need friidump for it.. it might also work with isobuster.

23 (edited by tossEAC 2010-03-25 16:35:39)

Best settings for Athlon 64-Bit so far,

friidump -d v: -c 1 -x 4 -T 3 -6=[04,48] -i America's 10 Most Wanted (Europe).iso

2555-3400 MB/h --> 1945 MB/h --> 2500 MB/h @ 11% --> 3060 MB/h @ 26% --> 3320 MB/h @ 40%

Same settings for P4 Duo

2400 MB/h @ 14% --> 2489 MB/h @ 23% --> 2515 MB/h @ 31%

could be differences as I am using different PS2 discs on each sytem.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

24 (edited by tossEAC 2010-03-25 17:38:33)

Tell me something I need friidump for and can use on my drive GameCube and Wii don't work, do they?

I have been trying stuff that doesn't need raw dumping so far and it seems to be working ok, can x360 discs get dumped with frii.

Or how about those heavily protected DVD-Video, the special batch Sony Made for certain anime films, they wont dump properly with anything, and have seemed to pack inabout 3% with frii, thats about the point isobuster packs in.

I'VE HAD AN IDEA, I'M DOING AN XBOX1 DUMP. WISH ME LUCK, HMM IS IT AROUND THE 10% POINT THAT THE DUMPING SLOWS  DOWN.

NEARLY RIGHT 8%, AND MY PC HAD TO BE HELD IN POWER PRESSED MODE TO SWITCH IT OF. THATS SEVERAL TODAY.

SO FAR MY ONLY WORKING FRIIDUMPS HAVE BEEN WITH SIMPLE COPY PROTECTION, NOTHING EXOTIC LIKE XBOX, NGC, OR BAD SECTOR DVD-VIDEOS. IS THAT ALL I CAN EXPECT FROM THE SH-D162D

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

XBOX360 DISC SEEMS TO BE GOING FOR IT --> 26% @ 6000MB/h

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.