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.
You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
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.
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)
could you check the log for this disc ?
Also try to use subdump.
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.
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.
Madroms wrote:could you check the log for this disc ?
Also try to use subdump.
subdump added.
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 ?
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.
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.
re-ripping with my ASUS drive with /be also yielded the correct result.
No need to use /be except plextor.
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.
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.
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.
I use it on Windows 7 64 bit Enterprise without an issue, and no, it's not an illegal version.
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.
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.
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.
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.
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.
Similar problem https://github.com/saramibreak/DiscImag … /issues/41
Try to use DVD model of plextor if you have.
That kind of sucks, the DVD drives are awful and unreliable
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.
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/
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).
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.
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/
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.(....`.
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.