2,426 (edited by Nexy 2020-02-22 05:15:33)

He told me he didn't have code, and that he just edited the command in the buffer with bushound.

Also latest version will crash if the drive tray is open.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

2,427

sarami, could you check the log for this disc ?
http://forum.redump.org/topic/26845/pro … rihen-jpn/

- with desync so tracks with sub indexes created
- track 14 is reported as Audio when, I think, it must be mode 2 like all the other tracks (a movie .dat file points to the track 14 LBA)

Saturn Database {-} Retro Deals search engine that helps you find stuff (plextor drives, games, etc.) easily on eBay {-} My Redump Logs

2,428 (edited by sarami 2020-02-23 12:54:48)

Madroms wrote:

could you check the log for this disc ?

Also try to use subdump.

Nexy wrote:

he just edited the command in the buffer with bushound.

Could he really get the scrambled sector data by the method? I can't use bushound readily because it's really expensive.

2,429

Hi, sarami.  There's been some discussion in one of the discord channels this morning about an apparent bug in DiscImageCreator, at least as far as support for the ASUS BW-16D1HT goes.  The quick background is that we noticed a discrepancy between how my ASUS drive rips disc 1 of Wing Commander: Prophecy and previous dumps with Plextor drives.  Ripping my own disc with a Plextor yielded the same results as the other Plextors, and re-ripping with my ASUS drive with /be also yielded the correct result.  So at RoyBatty's request I started using /be as a default option.

Today, I noticed that using that option results in mismatches in ripped audio tracks.  As a specific example, when ripping this Quake II disc:
http://redump.org/disc/43204/

if I omit /be, all ripped tracks match the redump entry.  If I include /be, the data track matches, but all audio tracks have different checksums.  I've observed this on two other discs as well.

For your reference, here are the logs and stdout from two rips, the first without /be, the second with:
https://www.legroom.net/public/q2-c2-4000-0-s-2.txz
https://www.legroom.net/public/q2.txt
https://www.legroom.net/public/q2-c2-4000-0-be-s-2.txz
https://www.legroom.net/public/q2-be.txt

Please let me know if you need any additional details.

2,430

sarami wrote:
Madroms wrote:

could you check the log for this disc ?

Also try to use subdump.

subdump added.

Saturn Database {-} Retro Deals search engine that helps you find stuff (plextor drives, games, etc.) easily on eBay {-} My Redump Logs

2,431

sarami wrote:

Could he really get the scrambled sector data by the method? I can't use bushound readily because it's really expensive.

It's been free for personal use for some time now ?

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

2,432 (edited by sarami 2020-02-24 13:39:59)

Nexy wrote:

It's been free for personal use for some time now ?

Free version is limited.

Up to 32 commands can be captured
Only the first 8 bytes of each data transfer are captured
Runs only on 32-bt Windows, XP and later

I'm working ASUS on Win10 64bit.

Madroms wrote:
sarami wrote:
Madroms wrote:

could you check the log for this disc ?

Also try to use subdump.

subdump added.

LBA 91152 is the start address of track 14 on TOC.

      Data Track 14, LBA    91152 -    93436, Length     2285

But It's the end of address of track 13 on sub.

LBA[091151, 0x1640f]: P[3f], Q[411301040808002017264de6]{ Data,      Copy NG,                  Track[13], Idx[01], RMSF[04:08:08], AMSF[20:17:26]}, RtoW[0, 0, 0, 0]
LBA[091152, 0x16410]: P[3f], Q[41130104080900201727f796]{ Data,      Copy NG,                  Track[13], Idx[01], RMSF[04:08:09], AMSF[20:17:27]}, RtoW[0, 0, 0, 0]
LBA[091153, 0x16411]: P[00], Q[41140100000100201728797b]{ Data,      Copy NG,                  Track[14], Idx[01], RMSF[00:00:01], AMSF[20:17:28]}, RtoW[0, 0, 0, 0]

It looks like real sub indexes. F1ReB4LL judges it.

nitro322 wrote:

re-ripping with my ASUS drive with /be also yielded the correct result.

No need to use /be except plextor.

2,433

sarami wrote:
nitro322 wrote:

re-ripping with my ASUS drive with /be also yielded the correct result.

No need to use /be except plextor.

I don't think I follow.  Without /be on the ASUS, it produces a different file than that ripped by Plextor.  Clearly the same disc producing different output depending on the drive used to rip it is not desired.

2,434

To get scrambled sector(s), plextors use 0xd8 while other drives use 0xbe with cdda flag.
If /be is used, 0xbe with all flag is set forcibly. As the result, it can't get scrambled sector(s).
In other words, it can't get correct combined offsets.

nitro322 wrote:

if I omit /be, all ripped tracks match the redump entry.  If I include /be, the data track matches, but all audio tracks have different checksums.

If you want to dump mixed mode disc on ASUS, do not use /be.

2,435

I use it on Windows 7 64 bit Enterprise without an issue, and no, it's not an illegal version.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

2,436

sarami wrote:

To get scrambled sector(s), plextors use 0xd8 while other drives use 0xbe with cdda flag.
If /be is used, 0xbe with all flag is set forcibly. As the result, it can't get scrambled sector(s).
In other words, it can't get correct combined offsets.

nitro322 wrote:

if I omit /be, all ripped tracks match the redump entry.  If I include /be, the data track matches, but all audio tracks have different checksums.

If you want to dump mixed mode disc on ASUS, do not use /be.

That makes sense.  Thanks for clarifying.

One last question, if you don't mind - for single track discs, would you recommend always setting /be with ASUS drives?  My concern is with discs like that Wing Commander Prophecy example, where I wouldn't know there's a problem unless there's already another good dump that doesn't match.

2,437

nitro322 wrote:

My concern is with discs like that Wing Commander Prophecy

Is it this disc? http://redump.org/disc/12961/
If yes, as I said, large ofs disc is not supported yet on Asus.
If no, upload logs, please.

2,438

sarami wrote:

Is it this disc? http://redump.org/disc/12961/
If yes, as I said, large ofs disc is not supported yet on Asus.
If no, upload logs, please.

Yes, that's the disc.  Offset issue noted.  What's odd about that case is that it did get a correct (correct as in matching the plextor, at least) dump with /be, even despite the large offset.

2,439

Because data sector can be dumped without offsets using 0xbe opcode. It's normal method. Almost all CD dumping tools (Isobuster, CloneCD etc.) use 0xbe.

2,440

Hi sarami. I ran into some issues dumping a multisession pc disc today with the latest github release where it would timeout around the end of the first session and DIC would just hang.

I used the latest test build you posted in this thread and the dump completed with some errors. I was hoping you could check the logs and let me know if the dump is ok.

The disc in question is the US version of http://redump.org/disc/56890/.

Logs: https://mega.nz/#!HvRjRAzI!g7wn70ZdO0VE … bSJDcT9nb8

If you need any more info let me know. Thanks.

2,441

Similar problem https://github.com/saramibreak/DiscImag … /issues/41
Try to use DVD model of plextor if you have.

2,442

That kind of sucks, the DVD drives are awful and unreliable sad

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

2,443

sarami wrote:

Similar problem https://github.com/saramibreak/DiscImag … /issues/41
Try to use DVD model of plextor if you have.

That's a shame, but thanks for the quick response. Unfortunately my dvd model stopped recognizing 99% of discs a while back. I tried anyway to no avail.

The only drives I have at the moment are a Premium (which is what that dump was) and an ASUS (which can't dump multisession either). So I guess I'll just have to pick up another dvd model to dump this.

I confirm the problem. I can't finish the dump of one multisession disc (with multiple audio tracks). On both PX760 and 4012...

I've found a problem with dumping some DVD-Video discs using DIC.  Well, really, 2 problems.

First, starting with DIC 20200203, all of the Cube DVDs fail to dump, with the error being "nLBA 262, Directory Record is invalid".  DIC 20200204 is also affected, while 20191116, 20191223, and 20200120 are not.  This immediately stops dumping right at the start, with a 0-byte image file.

Secondly, DIC 20191223 and 20200120 produce an error with Cube DVD 01.  Unfortunately, my disc is rather scratched and it was hard to get a full dump, so I can't do too much testing and most dump attempts are polluted with other errors later on, but I did get a clean dump with 20200120 (which is the one I submitted there).  The specific error appears at the start and is this:

LBA[702695, 0xab8e7]: [F:ReadDVDForFileSystem][L:855]
    Opcode: 0xa8
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR

Dumping continues after the error, and (in that one lucky dump) I didn't get any other errors, including when it read that same area for actually writing.  (That area is all zeros, though).

These are all 8 cm DVDs, so perhaps that has something to do with it?  Unfortunately I don't have any regular full-size DVDs to compare with.

The first is probably a bigger issue since it completely prevents dumping these discs with current versions of DIC, but I am curious why the second one happens too.

Post's attachments

DVD08_20200120.7z 8.27 kb, 12 downloads since 2020-03-03 

DVD08_20200203.7z 5.11 kb, 12 downloads since 2020-03-03 

You don't have the permssions to download the attachments of this post.

2,446

Pokechu22 wrote:

First, starting with DIC 20200203, all of the Cube DVDs fail to dump, with the error being "nLBA 262, Directory Record is invalid".  DIC 20200204 is also affected, while 20191116, 20191223, and 20200120 are not.

Try to use the latest test version before reports bug. http://forum.redump.org/topic/10483/discimagecreator/

sarami wrote:

Try to use the latest test version before reports bug. http://forum.redump.org/topic/10483/discimagecreator/

Looks like both issues have been fixed!  Sorry about that; I assumed that since there weren't any more commits in the GitHub repo, there hadn't been any further changes, and didn't think to look for the test version.  (I was still unable to complete a dump of DVD 1, but that's expected due to the scratches on the disc, but it at least started).

2,448

Nexy wrote:

I use it on Windows 7 64 bit Enterprise without an issue, and no, it's not an illegal version.

ok, BW-16D1HT was recognized from Bus Hound. As a result, my drive couldn't get the last sector +3, +4 etc.
But I added reading code until the last sector +10. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Test plz. I want to see these logs.

2,449

I dumped a +2352 offset disc with my ASUS using the new test build. Hashes don't match my plextor dump.

Disc in question: http://redump.org/disc/66807/

Logs: https://mega.nz/#!rmgRCJaT!HGdlo_gedZ2i … 13rtgpQL9c

2,450

Agent47 wrote:

I dumped a +2352 offset disc with my ASUS using the new test build. Hashes don't match my plextor dump.

Last sector + 1 is good.

========== LBA[318828, 0x4dd6c]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : F5 CA D8 1C 5A 89 FB 26  C3 5A D1 FB 1C 43 49 F1   ....Z..&.Z...CI.
0010 : F6 C4 1A 43 E8 D0 CD ED  00 FF FF FF FF FF FF FF   ...C............
0020 : FF FF FF 00 71 D2 74 61  00 28 00 1E 80 08 60 06   ....q.ta.(....`.

Last sector + 2 is bad.

========== LBA[318829, 0x4dd6d]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : F2 73 D8 1C 5A 89 FB 26  C3 5A D1 FB 1C 43 49 F1   .s..Z..&.Z...CI.
0010 : F6 C4 8A 43 14 5F 4F 24  00 FF FF FF FF FF FF FF   ...C._O$........
0020 : FF FF FF 00 01 81 73 61  00 28 00 1E 80 08 60 06   ......sa.(....`.