Redump Forum

Lugamo wrote:

ehw wrote:BTW, if for whatever reason it seems like its way too slow (like 3+ hours) or seems like it stalled, feel free to stop it by using Ctrl+C and upload what you have. Some drives just don't like being bruteforced to that high value. I could probably restrain the values it's bruteforcing with but you never know if a vendor might be sneaky and put something at 3C FF FF or something, lol.

Thanks! Added

Here you go. I will try with another DVD later.

Edness wrote:Here's mine from a TSSTcorp SE-208DB.  Looks like 3C 02 00 returned 0x8BC bytes of scrambled sector data.  So did F1 84, which was offset by about 13.5 sectors (0x7800 bytes).  And F1 8A returned the PFI, funnily enough.
Disc used: [PC] FlatOut 2 (Europe) (En,Fr,De,Es,It) (Xplosiv)

Are PS2 discs also disallowed or not?  At first I started with a PS2 disc since I have way more of those on hand, but shortly after restarted with a PC disc.  I don't know if you look for specific patterns in testing, but my assumption was that maybe you expect the 0th sector to be empty, which is not the case on PS2 discs since those have the PlayStation 2 logo seen when booting a game XORed across the first 12 sectors.

You can use PS2 discs, absolutely. It's just that I've only ever tried standard DVDs that were mastered like a traditional DVD ISO disc, like something with a UDF or ISO partition as some other discs may be harder for older or other drives to read or might not have the same raw data that the program uses to identify it (like weird DRM or something).

Thanks for the submission!

BTW, new version pushed. This one adds a timeout of 20 seconds per bruteforce'd value to cover moments where it looks like the program is frozen. Hopefully it takes care of that...

I also noticed a small oversight with the F1 progress bar so hopefully that's fixed too.

https://github.com/hiddenpalaceorg/DVDR … 2023-10-01

I will also add my logs. I checked on BW-16D1HT, but with firmware 3.10 modded by RibShark

More logs from two drives (SOHD-167T and SH-216BB)
BTW: Is it possible to add a function to the program code that allows the program to end when the drive is not responding? My SH-216BB hang up when reading 256 sectors (F1 I think). It happened twice and each time I had to restart the drive from the power supply. When the drive was suspended, the program was still waiting for a response from it. It would be nice if the program restarted the drive in such situations, or if the drive stopped responding after some time, it would terminate its operation

MrPepka wrote:I will also add my logs. I checked on BW-16D1HT, but with firmware 3.10 modded by RibShark

Thanks! For some reason it should've found a working command but I think I might've boo boo'd the addition of a timeout because apparently sometimes when sg_raw timesout it causes the drive to reset which would clear the cache, which means we lose LBA 0 which makes everything after the first timeout potentially useless. I think that might've happened here. Do you remember when you were testing the drive when it exactly started to take a really long time for the progress bar to move?

I might have to revert the timeout thing and just have people CTRL+C it if it starts going really really slow. At least for the time being.

MrPepka wrote:More logs from two drives (SOHD-167T and SH-216BB)
BTW: Is it possible to add a function to the program code that allows the program to end when the drive is not responding? My SH-216BB hang up when reading 256 sectors (F1 I think). It happened twice and each time I had to restart the drive from the power supply. When the drive was suspended, the program was still waiting for a response from it. It would be nice if the program restarted the drive in such situations, or if the drive stopped responding after some time, it would terminate its operation

It's supposed to timeout as of the latest version after 20 seconds and move on to the next number...

With the BW-16D1HT, the progress bar did not move for a very long time, but rather at a normal pace
As for SH-216BB, I tested the latest version, but when the drive hang up, the 20-second timeout did not work, the program was constantly waiting for a response from the drive. Only when I stopped the program and restarted the drive and then resumed the program, did the program continue to run

TSST TS-L632H doesn't support or what happens?

Tested another drive I had laying around, as well as sent this in a chat with a couple of friends who were also interested in it, so there may be more to send soon.  The laptop HP SU-208CB drive I just tested here I'm like 99.1% sure is actually a rebranded TSSTcorp drive, so make of that what you will for which brand to put that under.  I also have a few more to test, those being an assortment of drives in other old PCs but that's for later.

It seemed to completely hang when it got to F1 05.  I couldn't kill the process or anything, so I ended up force shutting it down after like an hour which means it didn't flush anything to the log file either.  But 3C 02 00 got 0x8BC bytes of raw sector data, at least.  I re-ran just the beginning to get the basic drive info at least, but I don't feel like running the whole thing on that crappy laptop again, as it was excruciatingly slow.

Jason098 from the aforementioned group chat modified it slightly to run on Linux since almost everyone in my friend group uses it, which also means the get_dvd_drive_info() function had to be commented out for them.
There's also an odd edge case to consider: one of Jason's discs had "unexpected" data in the 1st byte of the PSN.  AFAIK, normally (if the PFI is anything to go by) the leftmost byte is unused so usually it's just 0x00, but that one disc had "random" values in there like 50030000, 20030001, etc.  It may be better to mask out the 1st byte and only check if the lower 24 bits equal to and increment from 0x030000 instead.  It's possible a field marked as "No" could actually be wrong and mislabelled due to this oddity.

There were some other drive issues he had too, like if the lower nybble of the 3C command ended with 0x0B, the drive would pretty much hang so we had to work around that as well (which I understand he also later brought up to you in another server.)

I made a new version to try to deal with the drive timeouts and potential possibility that it clears the cache when it does so. I don't have any drives on hand that does this so it needs testing:
https://github.com/hiddenpalaceorg/DVDR … 023-10-01a

It will reread LBA 0 so it puts it back on the cache again if a specific error is returned from sg_raw. Hopefully this helps a bit...

Edness wrote:Tested another drive I had laying around, as well as sent this in a chat with a couple of friends who were also interested in it, so there may be more to send soon.  The laptop HP SU-208CB drive I just tested here I'm like 99.1% sure is actually a rebranded TSSTcorp drive, so make of that what you will for which brand to put that under.  I also have a few more to test, those being an assortment of drives in other old PCs but that's for later.

It seemed to completely hang when it got to F1 05.  I couldn't kill the process or anything, so I ended up force shutting it down after like an hour which means it didn't flush anything to the log file either.  But 3C 02 00 got 0x8BC bytes of raw sector data, at least.  I re-ran just the beginning to get the basic drive info at least, but I don't feel like running the whole thing on that crappy laptop again, as it was excruciatingly slow.

Jason098 from the aforementioned group chat modified it slightly to run on Linux since almost everyone in my friend group uses it, which also means the get_dvd_drive_info() function had to be commented out for them.
There's also an odd edge case to consider: one of Jason's discs had "unexpected" data in the 1st byte of the PSN.  AFAIK, normally (if the PFI is anything to go by) the leftmost byte is unused so usually it's just 0x00, but that one disc had "random" values in there like 50030000, 20030001, etc.  It may be better to mask out the 1st byte and only check if the lower 24 bits equal to and increment from 0x030000 instead.  It's possible a field marked as "No" could actually be wrong and mislabelled due to this oddity.

There were some other drive issues he had too, like if the lower nybble of the 3C command ended with 0x0B, the drive would pretty much hang so we had to work around that as well (which I understand he also later brought up to you in another server.)

I'm not sure whether to trust when the left most byte is different because other bytes within the page might be altered randomly from different runs too. I'm making notes of when this happens in the notes field but I'm looking for when the first 4 bytes are exactly 00 03 00 00 to know that it's workable for sure.

Keep them coming lol.

MrPepka wrote:TSST TS-L632H doesn't support or what happens?

Try again? Maybe the drive doesn't like the disc and can't read it.

Sony DDU1611
https://mega.nz/file/JjhDWa4J#yQ7NM5jwH … dujWrBMOYg (The logs weigh over 1 GB, it's worth having a good connection to download them!)

ehw wrote:I made a new version to try to deal with the drive timeouts and potential possibility that it clears the cache when it does so. I don't have any drives on hand that does this so it needs testing:
https://github.com/hiddenpalaceorg/DVDR … 023-10-01a

It will reread LBA 0 so it puts it back on the cache again if a specific error is returned from sg_raw. Hopefully this helps a bit.

OK, these are the new logs