That did the trick. Thanks again!
2 2024-01-19 15:45:37
Re: Firmware for BW-16D1HT (3 replies, posted in General discussion)
MrPepka wrote:
Thanks! Will give this a go after work today.
3 2024-01-19 03:43:31
Topic: Firmware for BW-16D1HT (3 replies, posted in General discussion)
Hi, all. Hoping someone can give me a pointer.
I have a new BW-16D1HT to replace an older one that failed. The old drive worked great (with the odd exception or two) with DiscImageCreator. However, my new drive errors every time. Per the wiki, it looks like I need either firmware 3.02 (DE) or a patched version of 3.10.
I've already downgraded the drive to 3.10 for ripping with MakeMKV and that works great. But I'm struggling to find a DIC-compatible firmware. All of the firmware packs for MakeMKV appear to have been updated to versions 3.03 or 3.10, and I'm unable to find the 3.02 firmware. As for 3.10, I see that RibShark created it, but can't find a download link for that either.
The closest I've been able to find is an ASUS 3.02 flasher for Windows, but that doesn't help since I'm on Linux. I need just the firmware bin file.
Can anyone point me to a compatible firmware file? or maybe tell me what to search for? My google-fu is failing me.
Thanks.
4 2020-12-28 21:15:36
Re: Primary Volume Descriptor (PVD) Dumper in Python (3 replies, posted in General discussion)
Ha, man, that's some advanced formatting going on there. Impressive. I with a knew about that a while ago, would've probably saved a couple hours or so cumulative over all the discs I've dumped. Very much appreciate you sharing!
5 2020-12-20 04:53:16
Re: Primary Volume Descriptor (PVD) Dumper in Python (3 replies, posted in General discussion)
I know this is an old post, but wanted to say thanks. I run Linux and can get the PVD from games with this hexdump command:
hexdump -C -n 96 -s 33568 game.isoBut it doesn't output the results in exactly the same format as IsoBuster, and since the form validator seems to compare against that IsoBuster format I always have to massage the output a bit to get it accepted. Just stumbled across this for the first time and tried it out and it works great. Will save me a bit of time and effort for each disc I rip going forward.
Thanks!
6 2020-06-24 21:42:03
Re: [DONE] Wiki access (2 replies, posted in Guests & account requests)
I'm in. Thanks!
7 2020-06-23 17:07:37
Topic: [DONE] Wiki access (2 replies, posted in Guests & account requests)
Hello. Would it be possible to get access to the wiki? I see a handful of games on the missing lists have since been dumped, and would like to tidy those up.
Thanks.
8 2020-02-27 06:22:00
Re: DiscImageCreator (3,497 replies, posted in General discussion)
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.
9 2020-02-26 02:54:45
Re: DiscImageCreator (3,497 replies, posted in General discussion)
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.
10 2020-02-24 16:22:13
Re: DiscImageCreator (3,497 replies, posted in General discussion)
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.
11 2020-02-23 21:03:33
Re: DiscImageCreator (3,497 replies, posted in General discussion)
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.
12 2020-02-14 06:08:53
Re: DiscImageCreator (3,497 replies, posted in General discussion)
Hello. I've been using DIC to rip a number of old DOS and Windows games under Linux. I ran into a problem ripping one particular game - MegaRace. I can rip a copy with multiple other utilities from multiple drives with no error, but DIC always reports "[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 2". No C2 errors reported, just that 2 errors described, regardless of how many times I try cleaning and resurfacing the disc.
Someone on Discord stated it's because of the large offset on the disk (1101 samples) and likely a bug in DIC. He suggested I report the issue here. The logs can be found here:
https://www.legroom.net/public/megarace.txz
Please let me know if any additional info is needed, or if I can do anything to help test.
Thanks.
13 2020-01-19 18:23:30
Re: PC CD/DVD Ripping/Submission Help (4 replies, posted in General discussion)
Hi, zcal. From what I've pieced together, !submissioninfo.txt basically just compiles information from the various files creatd by DiscImageCreator. I'm pasting the output below from one rip as an example:
It just makes it easier to copy/paste your submission. It's possible to run DICUI.Check_1.15-net462.zip under Linux with wine/mono, but you can also manually add the data using this as a template and not bother with !submissioninfo.txt.
Just as an FYI, I had some discussion and got a few additional questions answered in the following thread. May be helpful for you as well.
http://forum.redump.org/topic/22980/add … nux-cdrom/
And last of all, welcome!
Common Disc Info:
Title:
Foreign Title (Non-latin):
Disc Number / Letter:
Disc Title:
System: IBM PC Compatible
Media Type: CD-ROM
Category: Games
Region: World (CHANGE THIS)
Languages: Klingon (CHANGE THIS)
Disc Serial:
Ringcode Information:
Mastering Code (laser branded/etched):
Mastering SID Code:
Data-Side Mould SID Code:
Label-Side Mould SID Code:
Additional Mould:
Toolstamp or Mastering Code (engraved/stamped):
Barcode:
Error Count: 0
Comments: [T:ISBN]
Contents:
Version and Editions:
Version:
Edition/Release:
Extras:
Primary Volume Descriptor (PVD):
0320 : 20 20 20 20 20 20 20 20 20 20 20 20 20 32 30 30 200
0330 : 31 30 39 30 37 31 35 31 32 34 37 30 30 00 32 30 1090715124700.20
0340 : 30 31 30 39 30 37 31 35 31 32 34 37 30 30 00 30 01090715124700.0
0350 : 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 000000000000000.
0360 : 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0370 : 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Copy Protection:
Copy Protection: (CHECK WITH PROTECTIONID)
Tracks and Write Offsets:
DAT:
<rom name="Serious Sam - The First Encounter.bin" size="583524144" crc="a6d4f0f4" md5="1649a1a19ed2fb611cadc62a81279457" sha1="ef85bbc07a2f281db93734e954ddce8913258d9b"/>
Cuesheet:
FILE "Serious Sam - The First Encounter.bin" BINARY
TRACK 01 MODE2/2352
INDEX 01 00:00:00
Write Offset: -1214 2019-12-23 03:31:05
Re: bin2wav (8 replies, posted in General discussion)
Hi, sarami. Thanks for this. I discovered your program a while back and used it to convert a good many of my rips to WAV so I could further compress them with flac. Works great, but I just picked up a MiSTer that I'm trying to get configured for Sega CD and Turbografix-CD support and ran into a problem... my FLAC-based backups that work so well in a full PC environment don't work quite as well on MiSTer. :-(
Since you're doing a lossless conversion of the audio data here from "bin" to WAV format, is it possible to reverse that to convert WAV back to bin? Seems like it should be doable, but of course I have no idea how much work would be involved.
Have you given something like this any thought? Seems like it'd be a useful feature even regardless of MiSTer support, as it'd provide an easy way to convert a rip back to its original format for verification against redump's DAT files. Otherwise, I'd have to re-rip all of my games, which I'd prefer not to do if possible.
Would appreciate if you could at least share some feedback on this, whether it seems feasible or not. Thanks!
15 2019-06-04 05:04:26
Topic: PC CD/DVD Ripping/Submission Help (4 replies, posted in General discussion)
Hi. Brief background, with specific questions to follow:
I'm ripping my entire PC media collection, mostly older games for DOS, early Windows, and Linux. I'd like to verify my rips and contribute where possible, but the PC ripping guide and recommend software is entirely Windows-centric. I don't run Windows, so that's a problem for me.
I found that the DiscImageCreator CLI version has a Linux port available, which is great (thanks, sarami!). I don't seem to have one of the specifically recommended drives, but doing some basic testing with a Quake III CD I seem to get positive results. The resulting bin file matches as does the PVD timestamps. I can also rip the disc with cdrdao + toc2cue and get identical results as far as the bin/cue files go.
So that all seems promising as far as verification, but submission is a different store. DiscImageCreator creates a LOT of files. The guide says that DCUI will put the important bits in !submissioninfo.txt, but I don't have that file as, presumably, I'm using DiscImageCreator directly.
My questions:
1. Given the above (ripping under Linux and not using a "certified" drive), is it worth submitting rips for games that you don't already have included in the database, or would it be seen as untrustworthy?
2. If it's worth submitting, can someone point me to any templates or directions on how to manually assemble the information necessary for submission from the resulting DiscImageCreator files?
3. Once verified and/or submitted, is there any practical benefit to keeping all the additional files *besides* the bin/cue? CloneCD images are not well supported on Linux, I don't know what to do with the SCM or other files, and all of the text output, while interesting, don't seem particularly useful for my needs down the line. Just want to make sure I'm not missing I may regret later.
Thanks, all. Appreciate any guidance.
16 2018-08-08 00:47:49
Re: Redistributing DAT files? (3 replies, posted in General discussion)
Sorry for the delay, been away a couple of days.
That's awesome! To confirm, you're saying you're okay with me bundling the Redump DAT files with my verification script, including the restricted files? Just want to make sure I'm not misunderstanding, since you're saying downloads and I'm saying DAT files. Pretty sure we're talking about the same thing, but I wasn't expecting it to be so easy, so just but want to be sure.
17 2018-08-05 06:40:35
Topic: Redistributing DAT files? (3 replies, posted in General discussion)
Hello. I've written a utility to verify game checksums under Linux, using No-Intro (for cartridges) and Redump (for discs) DAT files as sources of truth. Currently, I just provide the script along with directions to download the various DAT files that are needed and copy them to the appropriate folder. To make it easier for anyone to get started with this, I'd really like to bundle the DAT files with the script or at least provide the ability to auto-download the DAT files for the user.
I'm working under the assumption now that any form of this is forbidden, so to be clear, I'm not doing anything like this now. However, I could find any explicit rules about this on the site, so I thought it'd be worth asking here to clarify.
1. Would it be okay to bundle and redistribute the generally available Redump DAT files with my script? What about the restricted DAT files (like PS3, 360, etc.)?
2. If no, would it be okay to provide functionality that auto-download the generally available DAT files from the site?
Obviously, full credit and attribution would be provided, and given this is a CLI Linux script, I'm expecting actual usage numbers to be pretty low. I wrote this for myself - if anyone else can benefit from it, that's just a bonus. :-)
Let me know what you think, please. I'm going to post a similar question on No-Intro's forum. And no worries if the answer to all of the above is "no" - I'm expecting that, to be honest. Still thought it worth asking, just in case.
Thanks!
18 2017-12-23 08:52:46
Re: [DONE] WIIU dumping (5 replies, posted in General discussion)
Thanks, Hiccup. Appreciate the clarification, and especially the pointer for the version. Turns out I only have one undumped disc - a newer version of Mario Kart 8. Thought I'd have a more to contribute, but oh well - I'll at least get this one posted shortly.
Thanks again.
19 2017-12-21 06:48:31
Re: [DONE] WIIU dumping (5 replies, posted in General discussion)
Hello. I'm currently dumping my Wii U games and would like to report any undumped games or versions that I may have. I can't find a specific guide for Wii U games (if I'm missing something, though, please refer me), but based on prior experience and looking at some existing submission samples I figured out most of it. Have a few questions for clarification, if you don't mind:
Version - where does this come from? This is the only field I'm outright failing to find.
Serial - this always comes from the stamp on the underside of the disc itself, right? or should it be read from the ISO?
Mastering Code / Toolstamp - is this expected to be different? Found two submissions for Super Mario 3D World (USA), and they have different mastering codes. The code on mine is different as well, and it's not a simple case of transposing an S and a 5 or something like that - the numbers are obviously different. Is that expected?
Barcode - I included the box barcode in my Xbox/360 dumps, but I don't see that being reported for Wii U dumps. Should I include it if I have the box? or just ignore it?
Thanks.
20 2017-07-01 09:32:36
Re: [SOLVED] Xbox 360 SSv2 help (4 replies, posted in General discussion)
Well crud. While doing some research on this I found this in the Xbox Backup Creator readme:
Drive SS XGD3 AP25 DRT
-------------------------------------------------------------
<SNIP>
Liteon DG-16D2S 1 2 Y N
<SNIP>
1 = The OEM SS is not fully compliant with iXtreme, use abgx to fix
2 = Firmware must be XGD3 flashed (post 13141)So, my particular drive, in addition to being a hassle to extract the key from, is also apparently incapable of support SSv2 in OEM mode, which is what XBC calls the drive without a true 0800 firmware connected through the x360usb. So, I figured out how to flash 0800 and have it directly connected to a SATA port on my computer now. Did a fresh SS extract and now it's giving me v2 and matches what's in the redump database.
So, awesome, but bleh. A large part of the reason I bought the x360usb device was to not have to flash different firmware on the drive for ripping. Oh well.
Pretty late now, so I'll start posting my rips tomorrow.
21 2017-07-01 06:21:36
Re: [SOLVED] Xbox 360 SSv2 help (4 replies, posted in General discussion)
That's my understanding as well. This is the LiteOn DG-16D2S out of my Xbox 360, which is an 0800 drive. As mentioned, I've connected via the X360usb Pro v2 device, which, to the best of my understanding, is supposed to allow me to read/rip/dump any game I'd like without requiring a special firmware to be flashed on the drive. Currently, it's still running the stock firmware. Am I mistaken?
When attempting to rip XDG3 games with my kreon drive, Xbox Backup Creator explicitly told me that those games could not be ripped. After connecting the current DG-16D2S drive, it still wouldn't read the discs until after I extracted the security key. Since then, everything appears to behave as expected, so I feel like the drive is compatible and I'm doing the ripping correctly, just that I'm missing something in the post-processing.
I'll try ripping another game in the database and see if I have the same issue. Probably won't have a chance to do that until tomorrow, though. In the meantime, I'm very open to any suggestions or feedback.
Thanks.
22 2017-07-01 04:17:41
Topic: [SOLVED] Xbox 360 SSv2 help (4 replies, posted in General discussion)
Hi. I recently purchased an X360usb Pro v2 to connect my 360 DVD-ROM drive to my computer and rip my XDG3 games. I've previously ripped my XDG2 games with a kreon-flashed drive and, after some guidance by Enker, figured out what I needed to do to post the appropriate details for undumped games here.
As far as I can tell the process for XDG3 games with the new drive is the same (aside from the SSv2 vs. SSv1 stuff), but I tested this out on Binary Domain and have an issue with the SS CRC. According to the already-posted copy, the SSv2 CRC is 14BDB677. However, I get the following:
original (pre-ss_sector_range): be6db3b4
post-pre-ss_sector_range: BE6DB3B4
abgx360 SS CRC = 662C7293 (RawSS = BE6DB3B4
None of those match the version in the database. When running abgx360 against SS.bin, though, I get this:
SS Version: 1
--------------------------------------------------------------------------
CT RT CID Tol Mod Typ Data CD Response Angle Deviation
-- -- -- -- -- -- ------------- -------- ---------- ----- ------------
15 C5 00 00 0DE8B4F6 BBAFDE04
Failed to find a drive entry for Challenge ID C5
14 04 00 00 395D6B74 E06ED777
Failed to find a drive entry for Challenge ID 04
<snip>Those "failed to find a drive entry" errors pop up after every line. It also says SS Version: 1 - I'm not sure if that's significant or not. I'm obviously missing a step, but I'm not sure what. Everything else matches perfectly; it's only the SS that fails to match. Can anyone point me in the right direction?
Just for some extra info, in order to rip games with my drive via the X360usb Pro v2 device, I first had to use a probe to extract the security key of the drive. After doing that, I was then able to properly see the drive and extract the ISO with Xbox Backup Creator. Don't know if that's relevant, sharing just in case.
23 2017-05-02 06:17:37
Re: [DONE] Account Request (5 replies, posted in Guests & account requests)
Thanks, iR0b0t. I'm in. Time to start learning the protocol for posting dumps. :-)