| View previous topic :: View next topic |
| Author |
Message |
denzilla
Regular
Joined: 03 Jan 2003
Posts: 141
|
 Posted: Sun Mar 19, 2006 11:28 pm Post subject: Questions for David.... |
 |
|
1. How are things on the ME front? Progress seems to have halted after PR10.
2. Is there any possibility of reliable support for Virtual Drives? It doesn't have to affect compatibility since bin/cue files could be made to comply with the internal TOC database just like a real disc. I can use Alcohol to boot CDs, but there are definite bugs and some games simply don't work right. |
|
| Back to top |
|
 |
dmichel
Admin
Joined: 04 Apr 2002
Posts: 1166
Location: France
|
| Posted: Mon Mar 20, 2006 9:40 am Post subject: Re: Questions for David.... |
|
|
| denzilla wrote: | | 1. How are things on the ME front? Progress seems to have halted after PR10. |
Yes, it's a bit frozen, I had stopped to work on ME to concentrate on ME-FX but I didn't expect it would take that long. ^^; It's not all bad though, all the work I did on ME-FX will go in ME too, mainly GUI stuff. Watch for a new ME shortly after ME-FX release.
| Quote: | | 2. Is there any possibility of reliable support for Virtual Drives? It doesn't have to affect compatibility since bin/cue files could be made to comply with the internal TOC database just like a real disc. I can use Alcohol to boot CDs, but there are definite bugs and some games simply don't work right. |
ME handle virtual drives like any regular drive, actually it doesn't even know if a drive is virtual or not. If things don't work right that's more the fault of Alcohol.
_________________
David Michel |
|
| Back to top |
|
|
NightWolve
Elder
Joined: 19 Apr 2002
Posts: 304
Location: Chicago, IL, USA
|
| Posted: Mon Mar 20, 2006 11:41 am Post subject: Re: Questions for David.... |
|
|
| denzilla wrote: | | 2. Is there any possibility of reliable support for Virtual Drives? It doesn't have to affect compatibility since bin/cue files could be made to comply with the internal TOC database just like a real disc. I can use Alcohol to boot CDs, but there are definite bugs and some games simply don't work right. |
We all just recommend using Daemon Tools for that since it works, it's freeware, and supports so many image formats. So there already is and was reliable support. I've been using it as long as MagicEngine has existed with BIN/CUE, ISO/WAV/CUE, CCD, etc. and I never had a problem. Though, I prefer the last 3.47 version to the new one.
Anyway, it's not the emulator's fault since it's the virtual drive software's responsibility to behave as closely as possible to a real drive. The same ASPI commands to read sectors should behave exactly the same way as they do for a real drive. So there's really nothing he could do.
_________________
Translation Projects: Xak 3, Ys 4, Ys 1&2 Complete
Boycott XSEED Games!
Last edited by NightWolve on Mon Mar 20, 2006 11:48 am; edited 1 time in total |
|
| Back to top |
|
|
denzilla
Regular
Joined: 03 Jan 2003
Posts: 141
|
| Posted: Mon Mar 20, 2006 11:44 am Post subject: |
|
|
I didn't use Daemon tools because I read it disables your IDE drives since it uses SCSI emulation instead of IDE. Can someone clarify this? Thanks for the update, David  |
|
| Back to top |
|
|
NightWolve
Elder
Joined: 19 Apr 2002
Posts: 304
Location: Chicago, IL, USA
|
| Posted: Mon Mar 20, 2006 11:49 am Post subject: |
|
|
Well, if it causes problems on your system, uninstall it. You would know if you had a problem instantly. But I've never heard of this. Disabling access to your real IDE CD-ROM drives?? That doesn't make sense. What you're talking about sounds like the issue with installing Adaptec's ASPI drivers and a certain registry flag if I'm not mistaken. I would need to know more detail about what exactly you read. Maybe somebody had a particular issue with their system, but this is not the normal case. Version 3.47 and below is pretty solid software and I've been recommending it for years. It's not dangerous to install it for testing to my knowledge.
_________________
Translation Projects: Xak 3, Ys 4, Ys 1&2 Complete
Boycott XSEED Games! |
|
| Back to top |
|
|
denzilla
Regular
Joined: 03 Jan 2003
Posts: 141
|
| Posted: Mon Mar 20, 2006 12:50 pm Post subject: |
|
|
| okay, I'll give it a go when I get home from work. One more question, though: David said that ME doesn't care/know that its reading data from a virtual Drive but is it normal to get a bad TOC warning from a bin/vue that was produced from a good TOC CD? I made an image of Dracula X and ME always says the TOC is bad when loading it. The CD never gives this warning when used. Thanks for your help! |
|
| Back to top |
|
|
NightWolve
Elder
Joined: 19 Apr 2002
Posts: 304
Location: Chicago, IL, USA
|
| Posted: Mon Mar 20, 2006 2:48 pm Post subject: |
|
|
That's right, it doesn't care provided the software accurately behaves as a real drive. Now, if I remember correctly, David did something special with Dracula X only. I think it checks the CRC of the data track and if it fails, it reports a bad TOC. This would likely indicate that you are not accurately dumping your CD-Rom to BIN/CUE image format, or again, perhaps it is your virtual drive software, so just wait till you try Daemon Tools.
http://www.daemon-tools.cc/dtcc/download.php?mode=Download&id=34
There you go.
_________________
Translation Projects: Xak 3, Ys 4, Ys 1&2 Complete
Boycott XSEED Games! |
|
| Back to top |
|
|
Squaresoft74
Elder
Joined: 19 Apr 2002
Posts: 366
Location: France
|
| Posted: Mon Mar 20, 2006 5:18 pm Post subject: |
|
|
| denzilla wrote: | | I made an image of Dracula X and ME always says the TOC is bad when loading it. |
As i already said countless time on RomShare (and many other places !  ), don't use Alcohol to make Bin/cue images of Pce/Pcfx discs !!
It doesn't properly appends pregaps and as a result , it generates faulty images.
Use good old Cdrwin and the tutorial in my homepage to make proper Pce/Pcfx bin/cue images. 
_________________
 |
|
| Back to top |
|
|
denzilla
Regular
Joined: 03 Jan 2003
Posts: 141
|
| Posted: Mon Mar 20, 2006 6:02 pm Post subject: |
|
|
k, I downloaded Daemon Tools and CDRWIN and everything is great now. Thanks for all your help. Sorry Square, I've been out of the loop for awhile and my memory sucks  |
|
| Back to top |
|
|
Squaresoft74
Elder
Joined: 19 Apr 2002
Posts: 366
Location: France
|
| Posted: Mon Mar 20, 2006 6:38 pm Post subject: |
|
|
Np bro, glad you got everything working fine now
_________________
|
|
| Back to top |
|
|
2X4
Member
Joined: 20 Jan 2005
Posts: 39
|
| Posted: Mon Mar 20, 2006 10:59 pm Post subject: |
|
|
After reading this, I recalled having similar trouble to what denzilla described, and I had only used daemon tools and cdrwin in accordance with the advice of the vets on this board. out of curiosity, i made an image from what was supposed to be one of nightwolve's RIGG archives, then loaded it in ME. Sure enough, I got the bad TOC warning at the bottom, which of course shouldn't happen since I took the appropriate steps. So I checked the TOC with Squaresoft's database, and everything matched except for the last track (an iso track) was missing. Because of the way RIGG archives are compressed, I don't think it's possible that I was missing one of the RAR parts, so why did this occur? I know this is kind of unimportant, I am just curious if anyone might know.
_________________
 |
|
| Back to top |
|
|
NightWolve
Elder
Joined: 19 Apr 2002
Posts: 304
Location: Chicago, IL, USA
|
| Posted: Tue Mar 21, 2006 10:19 am Post subject: |
|
|
| Squaresoft74 wrote: | | Use good old Cdrwin and the tutorial in my homepage to make proper Pce/Pcfx bin/cue images. |
You will need to rewrite those tutorials to use what will be my good ole TurboRip to make proper ISO/WAV/CUE images. CDRWIN is no good either in the consistency dept. as it turns outs, if you care about always producing exactly the same sized files on every machine. Also, don't let that Linux zealot over at Aaron's PC-EngineFX forum hear you saying nice things about CDRWIN, or he'll go pyscho and give you a lecture about how everybody should've just known years in advance about the greatness of burn-at-once, the cdrdao open-source, cross-platform counterpart as well as the evil pitfalls of using proprietary Windows software and thus being discriminatory to the poor Linux community... Seriously, this lunatic blames CDRWIN for allegedly changing the BIN/CUE format and thus causing inconsistent BIN size results. CDRWIN invents the BIN/CUE standard, these other software makers come along with their "ME TOO! ME TOO! I LIKE BIN/CUE TOO!" and add support for it, but not quite as accurate, and thus, its CDRWIN's fault (and Windows) cause they allegedly changed the BIN format internally!!! 
Long story, this dude had a bitchfest cause my Xak III patch didn't use burn-at-once to rip an image and then build a PPF diff based on the results from that. The premise was built into his bitchfest that I should've known better, I should've known it even existed in advance to have spared him the trouble of having to find a Windows machine (after boycotting Windows for years and being on Linux) to finally be able to apply the patch... Anyway.
| 2X4 wrote: | | Because of the way RIGG archives are compressed, I don't think it's possible that I was missing one of the RAR parts, so why did this occur? I know this is kind of unimportant, I am just curious if anyone might know. |
2X4, yes, with that particular RIGG archive, there will be no TOC match. I made those at a time before Square put this bold vision forth with the TOC Database, so had I known, I would've made my archives recreate the last backup track using the second one. It wasn't hard at all to do, and I would still be able to save the space, but oh well, it's too late now. Any archive that says in the nfo that it's not 1:1 will have that problem.
Oh, here's the old list. Any archive where you see "Yes" in the 1:1 field will be correctly identified by its TOC. If it's "No", then yeah, I excluded the backup track. It's about 13 of them that suck like that. It was a bad decision in retrospect and I wouldn't have done it with what I know now. It really matters when you burn a CD-R and use real NEC hardware, too. Real dumb move on my part.
_________________
Translation Projects: Xak 3, Ys 4, Ys 1&2 Complete
Boycott XSEED Games! |
|
| Back to top |
|
|
denzilla
Regular
Joined: 03 Jan 2003
Posts: 141
|
| Posted: Tue Mar 21, 2006 12:05 pm Post subject: |
|
|
| Quote: | You will need to rewrite those tutorials to use what will be my good ole TurboRip to make proper ISO/WAV/CUE images. Wink CDRWIN is no good either in the consistency dept. as it turns outs, if you care about always producing exactly the same sized files on every machine. Also, don't let that Linux zealot over at Aaron's PC-EngineFX forum hear you saying nice things about CDRWIN, or he'll go pyscho and give you a lecture about how everybody should've just known years in advance about the greatness of burn-at-once, the cdrdao open-source, cross-platform counterpart as well as the evil pitfalls of using proprietary Windows software and thus being discriminatory to the poor Linux community... Seriously, this lunatic blames CDRWIN for allegedly changing the BIN/CUE format and thus causing inconsistent BIN size results. CDRWIN invents the BIN/CUE standard, these other software makers come along with their "ME TOO! ME TOO! I LIKE BIN/CUE TOO!" and add support for it, but not quite as accurate, and thus, its CDRWIN's fault (and Windows) cause they allegedly changed the BIN format internally!!! Confused
Long story, this dude had a bitchfest cause my Xak III patch didn't use burn-at-once to rip an image and then build a PPF diff based on the results from that. The premise was built into his bitchfest that I should've known better, I should've known it even existed in advance to have spared him the trouble of having to find a Windows machine (after boycotting Windows for years and being on Linux) to finally be able to apply the patch... Anyway.
|
Are you being serious cause I can't tell? The first part sounds serious enough but then turns into what I think is sarcasm. I have notcied that the filesizes for the same game are slightly different with CDRWIN but I thought that was normal. Just want to make sure that I'm making good copies here. I have a 1:1 copy of Dracula X that i wanted to preserve before it became a victom of "CD Rot" that all copied CDs will fall fate to at some point. Following Squaresoft74's intructions I created the image and checked it with CDmage and it had no errors. ME also reports it as good during boot. |
|
| Back to top |
|
|
Squaresoft74
Elder
Joined: 19 Apr 2002
Posts: 366
Location: France
|
| Posted: Tue Mar 21, 2006 1:24 pm Post subject: |
|
|
I never had any issue using CDrwin nor been reported any bin size issue with the way i make my bin/cue images.
Any resulting iso/wav/cue i made or heard people made with my tutorial always ended up with proper TOC.
In what condition exactly did people observed a different bin size ?
Sure it was not because of them using an unsupported drive ??
GoldenHawk update Cdrwin on regular basis to fix issues that occure with newer drives.
Anyway, i'll gladly add a dedicated tutorial for your tool.
_________________
|
|
| Back to top |
|
|
NightWolve
Elder
Joined: 19 Apr 2002
Posts: 304
Location: Chicago, IL, USA
|
| Posted: Tue Mar 21, 2006 2:19 pm Post subject: |
|
|
Yeah, I was being serious. I wouldn't be sarcastic about something like this. Now, you won't get any sector errors, because the ones that are extracted are done so correctly. That's not the issue. You will get size differences. I explained the test when I learned of this myself with a friend using our original copies of Dracula X. Lemme paste it or you could go back and read that other "forums are back" thread:
| Quote: | Well, what I'm trying to say is that this will guarantee consistent ripping/extracting results with the tricky transitioning tracks. Lemme explain with a test I conducted:
I have an original Dracula X CD-Rom. With my YAMAHA drive, the data track, track 2, goes from sector 3890 to 14036 using CDRWIN's "Select Sectors" feature in the Extract Disc Dialog. However, if I try to read up to 14037, I hit the pregap area, and the drive cannot read it, so CDRWIN errors out... Now, you would think this is true for everyone, but it's not. My friend tried the same test, and CDRWIN was able to read track 2 from 3890 to 14038. CDRWIN is unable to read at sector 14039 for HIM! So what happens is, on two different systems, you get two differently sized images, thus inconsistent results. TurboRip, on the other hand, will enforce the correct sector length when it comes to PREGAPs, and fill the end of the track with nulls. So every track will be the correct size, bottomline. |
On my machine, I can only read sectors 3890 to 14036. On his, he can read sectors 3890 to 14038. Those are two more sectors closer to the PREGAP area that he can get that I can't. The correct size of the resulting data track 2 in MODE1/2048 is 20,785,152 bytes. That's 10,149 sectors.
Now, if I can only read up to 14036, that's 14036-3890+1 = 10147 sectors. My ISO is two sectors smaller than what it should be... His is 14038-3890+1 = 10,149 sectors which is correct.
Two different machines, two different drives, and you'll get a result where my data track is smaller. This is dealing with the PREGAP, so those sectors are all NULL, but it's that the sizes will be different that's the issue. If I do a full BIN/CUE rip, it's gonna be smaller, because the first PREGAP error happens at sector 14037. You get the idea.
That's why, I used think people were just not correctly subtracting the 150 or 225 sectors when dumping tracks that involved PREGAP. It's true that was also a problem, but now I know that not all drives will error out at exactly the same PREGAP sectors.
Friend's name edited out for privacy:
| Quote: |
XXXXXXXXX: the 2 seconds prior to 014188 is defintely undefined and not meant to be read
XXXXXXXXX: or rather
Sef1roth: OK, yes, 3890 - 14188.
XXXXXXXXX: the 2 seconds prior to index 0 of track 2 (whereas TOC points to index 1
XXXXXXXXX: )
Sef1roth: Now, how much do you need to subtract?
Sef1roth: I think I was 152.
XXXXXXXXX: that's different by drive
Sef1roth: ???
Sef1roth: Really?
XXXXXXXXX: that 2 second area is undefined
XXXXXXXXX: some can read it
XXXXXXXXX: and what's more
XXXXXXXXX: CDRWIN likes to do a block read
Sef1roth: Well, it's not CDRWIN per say.
Sef1roth: ASPI is unable to read it.
XXXXXXXXX: so if you specify even 1 unreadable sector
Sef1roth: Using wahatever.
XXXXXXXXX: then the batch is toast
|
Now, don't freak out. It came as news to me. Drives aren't supposed to be able to read that PREGAP undefined area, some can though. But also, the ones that error out, don't always error out at the same spot when you get close to where the PREGAP starts. So yeah, I believe that this has partly been the explanation for all the ISO tracks out there that are the wrong size.
_________________
Translation Projects: Xak 3, Ys 4, Ys 1&2 Complete
Boycott XSEED Games! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
