PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Bonknuts on April 02, 2012, 08:11:01 AM
-
Taken from the MSR thread (without the drama)
I was able to rip MSR's raw data as a MODE1/2352 binary file. According to TheOldMan, this is the correct format for pressing. CDRWIN is able to rip the data, but first it had to be mounted to a virtual drive. Daemon Tools was not cooperating with CDRWIN, so I installed Alcohol 120% instead, and it did the job beautifully. So from here, I guess it's just a matter of getting discs that work, and a burner that is compatible with CDRWIN, as none of ours currently are.
Oh good. You got it to work. lol, that means I won't have to do it for you again (with the real build instead of a beta ISO).
Though, you'd be wise to get CDRWin to function properly and use that to do the ripping in order to remove all further doubt about the pressing issues. If you can't get it to work (CDRWin is kind of a dick), I can do it for you. I've got CDRwin operating on a few machines. Sometimes the entire trick is to use a different version of CDRWin (like 3.0D9erAlpha instead of 3.0D9erBeta). Other times the trick is to reboot your computer, or to use different ASPI drivers. Or, buy an old ass computer and set that shit up. There were times my laptop that Insanity was built on wouldn't work, and then 20 minutes later it would decide it wanted to work. Couldn't tell you why. I blame modern operating systems, goony drivers, and CDRWin's age.
AFAIK, when I told Keranu how to do it w/ CDRwin, he didn't seem to have any trouble, so you could probably use him too. I'm convinced two identical machines will have different success with CDRwin. It's that goony.
Look for the frog ASPI drivers. Those sometimes have better results, and can be used w/ CDRwin.
Insanity was not really done in any overly special way. More like, it was done the right way. Blame the devkit. You can't just use the ISO it creates. You have to use real CD creating tools to set the disc layout up properly for machines to stamp. CDRwin is the best tool for the job. You don't even need to pay for it! Best results come at 1x, and demonstration mode operates at 1x only. Pretty nice perk, lol.
However, had I known for sure MSR wasn't being prepared in the way OldMan finally mentioned, and that you were manually relocating the data yourself, I would have said something. Manually relocating the data track is one way to get errors.
Though, I did mention all of these details a few times on IRC when Insanity was pressed and the entire channel was erect in the pants about new pressed CDs and wanted to know how it happened. This included all of the details and comical stories about CDRwin, and 1x SCSI CD burners. I probably shouldn't have assumed everyone remembered that crap. When I kept saying "Insanity didn't do anything special", I assumed it was already understood that you had to do the MODE1/2352 setup, hence me being confused as to why your stuff wasn't working. I had some suspicions, but didn't say anything since you seemed sure it was being done right.
Maybe it's time this information gets posted so people can refer to it so this doesn't happen again.
EDIT: OH, and make sure you f*ckin' close out the disc session. Omitting that step is problems.
I'm confused here. Mode 1 /2048 and mode 1/ 2352 are the same thing, except 2352 is raw containing the error correction bytes for the data. Where as cooked mode(2048) requires the CDR software to build that during burn time (which is why it can be ripped back as raw 2352 mode). Are you saying that current burning software is producing incorrect burns? If that's so, then why are they working fine on the real systems as CD-Rs? Or is there something else that CDRWIN is doing to the TOC that other recording software isn't?
-
It's not that so much as it is the ISO produced by HuC isn't suitable to place within the CD-layout as is, where Rover put it.
If you mount it, and extract it, and then use the resultant bin/cue to setup the CD, you'll be on your way to having it work.
You also can't use the warning track built in.
You can take a CD burned this way and copy it with just about any program and it will be fine. I made a few quick backup copies of the Insanity masters with like IMGBurn or something and they were all 100% verified at Nationwide. (I had them check them all)
Long story short: The problem lies with HuC's produced ISO, and how you throw it around on a CD. Shit doesn't line up, you get overlaps and layout issues, and pressing houses don't like it.
EDIT: also, I could be wrong, but I do remember reading somewhere once that Nero burns shit in Mode 2 even if you tell it mode 1. I'm not sure how true this is, since I don't use Nero.
editedit: I am also bad at explaining shit like this.
-
Long story short: The problem lies with HuC's produced ISO, and how you throw it around on a CD. Shit doesn't line up, you get overlaps and layout issues, and pressing houses don't like it.
Haha, but I want the long version of the story.
So you omit the 'warning' audio track in Insanity? So it's a single data track layout and with the data track as the first track?
EDIT: also, I could be wrong, but I do remember reading somewhere once that Nero burns shit in Mode 2 even if you tell it mode 1. I'm not sure how true this is, since I don't use Nero.
Not that I've ever seen. And I've analyzed burned discs from Nero, verified as mode 1. I've forced cooked data tracks as mode 2, form 1 and IIRC it didn't work on the PCE. That was quite a long time ago though.
-
not quite. OldMan has a really good explanation of it that I am going to find and repost, since I blow at explaining shit, and he's already got it nicely explained.
He's got a better knack for explaining technical details without using words like "thing" and "shit" everywhere, lol
-
not quite. OldMan has a really good explanation of it that I am going to find and repost, since I blow at explaining shit, and he's already got it nicely explained.
He's got a better knack for explaining technical details without using words like "thing" and "shit" everywhere, lol
Cool :D
-
http://www.isobuster.com/help.php?help=190
and
What I remember from years ago....
Cds have a set of track indexes, one for each song. Normally, you would think the indexes start with 1, but for some reason they actually start at 0.
Most cds have a 2 second (150 sector) gap between songs. Normally, the song begins after this gap, which is where index 1 points. So, when you play a CD, it looks at track index 1 to see where to begin playing.
It is possible to make a CD where the music plays continuously. This is where the screwy indexes come in: I -think- when the cd goes to switch tracks, it plays the pre-gap area (at index 0) as it changes. In any case, it is possible to eliminate the gap between tracks....And that's what the turbo CD's do: the first part of the cd is a continuous stream of data, that happens to have two index points. (And this is the source of the DDPMS error. The indexes are wrong in some way).
Keep in mind that -even if it's not used- the track index 0 has to be set. And that's part of what screws things up.
Now, consider what HuC does: it bundles all the files together, and creates a -valid- iso file. That's right, track indexes and all. If you burn that directly to a CD, there's no problem. It's only when you try to put something in front of (or after) that track that there are problems, namely, that the track indexes are wrong. (What is track 1 in the iso is now actually track 2. And since Huc doesn't know about anything else on the disc, the rest of the indexes are missing.)
If you rip the track (either by mounting the iso or burning a CDR), the indexes vanish - they are not saved as part of the ripping process. So now you have the raw data, with no extra crap, and can put it where you want it. You just have to make sure it gets burned in the right format (Mode 1 / 2352 bytes per sector). Unfortunately, it's hard to find a program that will let you do that anymore. Everything expects a 'standard' CD format.
and
** Before you send new masters **
1) double-check and make sure the game works. A few times.
2) Make sure the burn process is repeatable. Do you get -exactly- the same cd from two rips on two different cds? You do -not- want slightly different masters.
3) Make more than 1 master. On different brands of cd, if possible. Our biggest problem was finding a brand that burned right without any errors. Most brands have drop-outs that the ECC corrects, but the mastering process hates.
Good Luck.
(ps. we went through some of the same bullsh*t. It took 2 months to get insanity actually pressed. And about 20 different masters. So don't give up. It can be done)
-
Yep. That's the post right there.
My version of it is "shit don't line up", like posted above. lol. (I should work on my technical explaining abilities one day)
Anyway, DEFINITELY test the f*ckin masters you send out. Especially since you load/do tons of Cd shit for cutscenes. You don't want to get halfway thru the game and have f*cked cutscenes, or garbled bullshit, or a plain unreadable disc.
Use silverbacks. f*ck that gold-shit.
Don't forget to close the session either. That'd be pretty bad.
Basically what happened is you took the ISO and shifted it ahead 1 track, so the whole thing is misaligned.
EDIT: Oh, and it didn't take 2 months to get it pressed, lol. :)
I mailed it at the end of September, and the discs we're here November 6th or something? The turn around time was pretty decent overall. From the time they got the verified copies, it took ~week to complete and ship. Add in the bullshit-weekend-crap from UPS not delivering on weekends, and it went pretty fast overall.
The actual turn around time was just over a week. Turnaround time doesn't count in you shipping stuff, and them shipping stuff back to you. Sort of sucks.
Our only hangup is the first master I sent had a tiny nick in it (from testing probably?) so they wouldn't even bother to look at it. We just had to burn some more and fire them all out.
Our disc never had a single layout issue. Just a little hairline nick on the surface.
EDIT EDIT: I forgot there aren't 28 days in October. I'm dumb.
-
What I remember from years ago....
Cds have a set of track indexes, one for each song. Normally, you would think the indexes start with 1, but for some reason they actually start at 0.
Most cds have a 2 second (150 sector) gap between songs. Normally, the song begins after this gap, which is where index 1 points. So, when you play a CD, it looks at track index 1 to see where to begin playing.
It is possible to make a CD where the music plays continuously. This is where the screwy indexes come in: I -think- when the cd goes to switch tracks, it plays the pre-gap area (at index 0) as it changes. In any case, it is possible to eliminate the gap between tracks....And that's what the turbo CD's do: the first part of the cd is a continuous stream of data, that happens to have two index points. (And this is the source of the DDPMS error. The indexes are wrong in some way).
Keep in mind that -even if it's not used- the track index 0 has to be set. And that's part of what screws things up.
Now, consider what HuC does: it bundles all the files together, and creates a -valid- iso file. That's right, track indexes and all. If you burn that directly to a CD, there's no problem. It's only when you try to put something in front of (or after) that track that there are problems, namely, that the track indexes are wrong. (What is track 1 in the iso is now actually track 2. And since Huc doesn't know about anything else on the disc, the rest of the indexes are missing.)
If you rip the track (either by mounting the iso or burning a CDR), the indexes vanish - they are not saved as part of the ripping process. So now you have the raw data, with no extra crap, and can put it where you want it. You just have to make sure it gets burned in the right format (Mode 1 / 2352 bytes per sector). Unfortunately, it's hard to find a program that will let you do that anymore. Everything expects a 'standard' CD format.
Ok, that's the details I was looking for. But some of it doesn't make any sense. HuC doesn't set any indexes to the tracks, the CUE sheet does. The sys card bios always defaults to index 01 of any data track, regardless of where it is. All LBA offsets for data reading are relative to this point (there's an internal variable that grabs the current LBA of the current data track of index 1, and always adds the LBA offset to this). So moving a data track to the first track of the layout or the second track, all data offsets will be relative to this. The only time this changes is when you issue a data track change, in which all data offsets will be relative to that track (and starting with index 1).
Yellow book states that the minimum legal pregap (the gap between index 0 and index 1) must be a minimum of 2 seconds (or 150 sectors) but there are no maximum lengths defined (that I remember). Some turbo CDs have an index gap of 3 second while others have the minimum gap. But there always have to be two defined indexes to every track.
If mounting it as a virtual drive and then ripping it is fixing it, then it sounds like the cdr recording software is taking liberties with the CUE. Or rather, the virtual mounting software is creating a different layout. Mode 1 "raw" (2352) has all the sync, header, data, ecc, etc so the CDR software isn't given any choice. But in cooked mode, it's taking liberties. And from the sounds of it, the pregap sectors are being setup as audio. That sounds a lot like XA format (mixing different mode sectors within a track define).
So, did you still have an audio track as the first track in the Insanity layout?
-
HuC doesn't set any indexes to the tracks, the CUE sheet does. The sys card bios always defaults to index 01 of any data track, regardless of where it is.
Yeah, when I wrote that, it was what we figured was happening as we put Insanity togther.
Now, I'm not quite so sure. After a few deeper looks into some of the generated insanity files, I find myself
sorta wondering what really -is- going on there. We know it worked, but....
1) I couldn't find any traces of either a TOC or super-indexes in any of the files I looked at. Granted, I didn't do an
exhaustive check, but no signs of author/date/publisher etc in any of the files.
2) After ripping the file, I was rather surprised to find I had what appears to be a duplicate of the original iso file.
Again, I didn't check out every detail, but it looks like the data that got ripped was the same as the .iso.
So it should have worked.....(and is probably why it booted and ran)
must be a minimum of 2 seconds (or 150 sectors) but there are no maximum lengths defined (that I remember). Some turbo CDs have an index gap of 3 second while others have the minimum gap.
Not -quite- true. There is a way (damned if I can remember it, though) to have a pregap of 0 seconds, so tracks play continuously. I do know that some turbo cds are 2 seconds, and others are 3. I wonder if maybe that means the boot track has to be at a particular time/ sector boundary....
And keep in mind, Yellow book standards may not apply. Were they ratified/complete in 1988? (ie, cd-bios date)
it sounds like the cdr recording software is taking liberties with the CUE
Yeah. We tried a dozen or so times with Nero, before moving on to CDRWIN. Part of the problem is most likely something Nero does...
the virtual mounting software is creating a different layout. Mode 1 "raw" (2352) has all the sync, header, data, ecc, etc so the CDR software isn't given any choice.
Not so sure it's creating a different layout. Possibly just reporting it differently, ie, using an older style of track layout. Or ripping it may yet prove to be unnecessary - it might be possible to burn the iso 'as is' in a different program, and get a mode1/2352 track.
And from the sounds of it, the pregap sectors are being setup as audio. That sounds a lot like XA format (mixing different mode sectors within a track define).
I dunno if the pregap is audio or not, but from what I've seen and heard, track 2 is coming out as an XA mode 2 track. (Which is not the same as a mode 1 track, though it is very similar).
So, did you still have an audio track as the first track in the Insanity layout?
You haven't heard the infamous insanity "dumbass" warning by now? ;)
Yes, we still have it. IIRC, we even went to some length to make it the same length as the original warning. Just in case things had to be the right size. (Remember, we knew less then than we do now). The exact placement of Track 2 may have to be tinkered with, but it's a moot point until it can be burned as a mode 1/2352 track. :(
.........................................................
All of which does raise some questions for me, though. I still have most (All?) of the insanity files floating around on some backup drive. I think I will drag out the old 4x setup again and run some more tests on what boots, and what doesn't later in the week. Doesn't mean it will solve the mastering problems, but it may give us some clues as to why it doesn't work for mastering. And why turbo cds and windows have problems sometimes....
Right now, I have to catch up to spring. Yardwork time, guys.....
-
I remember an important detail to this mix. Man, it really sucks that so much of this was done at really idiotic hours (3am!). Most of it is just a coca cola/gas station hotdog haze at this point.
Remember when we were burning the disc, trying to use the HuC ISO, and CDRWin refused to use it?
It spit back numerous errors bitching about the format, and refused to burn... so IIRC, I went "hmm lets try this" and did the extract sectors crap, and we went with that and it worked.
Also, I have Insanity files here, if you need them. I have the entire folder, left in the exact same state as the day it was burned and shipped off to Texas.
Yellow Book came out in 85, by the way.
When you load up a HuC ISO, it says Track1 is the data track, so if you shove this into track 2, id figure this is an issue.
Also, I don't have time atm to sit and look into the details, but at a quick glance, the one generated by HuC lacks this at the head of the file:
00ffffffffffffffffffff0000020001
other than that, the two ISOs look similar. I wonder if HuC is not creating the ISO properly, omitting this heading info?
There are some other inconsistencies as you proceed downward. I think HuC is screwing up how it creates an ISO. HuCs is smaller. It contains all of the parts that the extracted BIN contains, but is missing chunks interleaved throughout.
seeing as the ISO's from HuC aren't really "proper", and they work anyway, it's possible what we've done is just burn a properly formatted CD, that still works for the Turbo, because we sort of hand-rolled everything so that there are no overlaps.
-
Oh, so it passed the master process then with the audio track first. Nice :D
Not -quite- true. There is a way (damned if I can remember it, though) to have a pregap of 0 seconds, so tracks play continuously.
It's been a few years, but I remember the yellow book document/pdf mentioning the legal spec was minimum of 2 seconds. And I remember one early copy protection software used pregaps of smaller than spec (which either wouldn't rip right and/or the software could detect was changed for burned copies). Indexes are like chapters in a track. When you play an CD of audio tracks continuously, it's supposed to play through all the indexes; it'll starting at index 00 of the next track in sequence. If you track skip, it skips to index 01 of the destination track. I remember this for a couple of live concert CDs back in the 90's. You can put audio or data in the pregap (for whatever the track define is). Doesn't have to be silence. I put a whole 7megabyte chunk of a data track in the pregap for the Lords of Thunder Dual boot CD first data track. ISO9660 format doesn't go by indexes. It uses a hard offset of 150 sectors from start (absolute 0 LBA). Where as the PCE uses index 01 and doesn't care where that index is. Thus, a disc that boots SegaCD and TurboCD. Though you could make ISO9660 layout specifically for PCE much easier than that. The starting port for the CDFS table is 16 sectors part 150 sectors. The layout can be setup to point index 01 to 150 sector mark with the TurboCD idenitification string and boot IPL. Plenty of room before the ISO9660 starting sector/string (SegaCD does this). But I digress...
Yeah. We tried a dozen or so times with Nero, before moving on to CDRWIN. Part of the problem is most likely something Nero does...
Ahh, so the mastering company's software (eclipse???) rejected the ones burned with Nero? Where any of those burns with the data track included as raw (2352) mode file? Or was that the point where you just went with CDRWIN's burn?
I do know that some turbo cds are 2 seconds, and others are 3. I wonder if maybe that means the boot track has to be at a particular time/ sector boundary....
And keep in mind, Yellow book standards may not apply. Were they ratified/complete in 1988? (ie, cd-bios date)
Yeah, index 1 has to align up with the identification string in the first sector of the ISO. But if the CUE file is setup with the PREGAP command, then there's nothing to worry. Pregap command just creates silence between index 00 and 01. So index 01 will point to the right offset. The only problem you run into is when you manually define index 00 and index 01 from a single file (raw or cooked). I ran into this very problem with the LOT dual boot cd. Nero (and some others) put a pregap of 2 seconds at the first track regardless if you setup index 00 manually or not. So that's why my CUE is missing that entry. But some virtual drive software (and for some emulators too), they assume the pregap is defined via index 00. It's a mess. Now, if the image was a single binary file (data and audio) there probably wouldn't be any problem since there's no room for interpretation for the CDR or virtual/mounting software.
I dunno if the pregap is audio or not, but from what I've seen and heard, track 2 is coming out as an XA mode 2 track. (Which is not the same as a mode 1 track, though it is very similar).
Hmm. I wonder. I've used Nero through out the years (not that - that means anything. Turbo itself seems to play anything), but I do remember when I was testing the PCE's setup for indexing an such - that reading back the disc info.. that the data track was listed as mode 1. But then again, this was Nero's own disc scanning app. Would be nice to verify it with a 3rd party program. What cdr media statistics programs do you recommend or used?
-
Also, I don't have time atm to sit and look into the details, but at a quick glance, the one generated by HuC lacks this at the head of the file:
00ffffffffffffffffffff0000020001
other than that, the two ISOs look similar. I wonder if HuC is not creating the ISO properly, omitting this heading info?
Yeah, there's a potential problem for some software I guess. ISO format suggests that the file format is 'cooked'. But it also used for the ISO9660 file structure track dump. They're two completely different file formats (both are cooked though). The program was probably expecting a literal 9660 spec'd file.
It contains all of the parts that the extracted BIN contains, but is missing chunks interleaved throughout.
You mean the ECC/EDC/SYNC/HEADER bytes? Those additional bytes are interleaved for raw binaries. HuC outputs cooked binaries.
-
When you play an CD of audio tracks continuously, it's supposed to play through all the indexes; it'll starting at index 00 of the next track in sequence. If you track skip, it skips to index 01 of the destination track
Right. But you have to monkey with the pregap area to get continuous play to happen. Nero has problems with that, iirc.
Ahh, so the mastering company's software (eclipse???) rejected the ones burned with Nero? Where any of those burns with the data track included as raw (2352) mode file? Or was that the point where you just went with CDRWIN's burn?
Nope. We couldn't get the cds to boot using nero. And we tried a lot of stuff before we gave up.
CDRWin let us set things up exactly the way we wanted, with no surprises.
Keep in mind, this was 2 years ago, and the version of Nero we used was old then :)
I keep thinking it got better, but it looks like it still has the same problems with odd formats.
....that the data track was listed as mode 1. But then again, this was Nero's own disc scanning app. Would be nice to verify it with a 3rd party program
We definately got different results from what Nero said and what CDRWin said. Heck, I can't even find a setting in Nero anymore that says mode 1, without it being an XA (mode 2) track....
But then, I hear it all the time: "Nobody uses that. Why keep it in?" One of the big reasons I don't let software auto-update :)
I ran into this very problem with the LOT dual boot cd
And I have to wonder: Would -it- have passed the mastering tests ?
The problem is not getting the game to run from CDR. Rover has that. The problem is getting the disc close enough to the mastering specs that it can be mastered.
And we won't know if anything we try works until he has the discs, in hand.
-
Our CD was never rejected by the pressing software. It was rejected by us. Nero gave annoying results so we stopped using it. CDRwin is the best bet for anything old and weird.
The .ISO from HuC is smaller than the .BIN from CDRWin.
This leads me to believe that HuC is omitting important pieces of the puzzle, and CDRwin is good enough to figure this out and correct it.
I don't have the time right now to sit and compare what all is missing
but
7575792 vs 6596608
That is a very noticeable difference in size. That's like 960kb. This is a significant amount of difference between the two files, and is so different that the two files do not even almost line up properly. I bet this is part of why Rover's CD has overlap issues. I can't be certain, but I almost wonder if MSR would press fine if you just reburn with the CDRWin bin/cuesheet as opposed to the HuC ISO/Cue sheet.
It would be a bit of a pain in the ass to experiment on that, since you would need to:
1) mount the final ISO
2) Extract the bin/cue w/ CDRWin
3) Append the music to the cuesheet properly
4) Burn a bunch of copies and mail them
5) See if they say its fine when it gets there
6) Rejoice or get pissed and try again!
Also, they spelled electronics as "electoronics" in the ISO.
that made me lol.
-
I noticed a considerable size difference as well... so I did a lil math on MSR's files...
The original ISO is 6,596,608 bytes
The BIN ripped with CDRWIN is 7,575,792 bytes
So then, the original ISO ends up being 3221 sectors at 2048 bytes per sector. Cool.
Now, I did the same calc on the BIN, based on the spec CDRWIN gives (2352 bytes per sector)... and lookie here... 3221 sectors. So that's an extra 256 bytes per sector.... hey, that all lines up. :)
-
So, this means (i think), that the actual problem is that HuC is making f*cked up ISO files and CDRwin fixes them.
-
That might be the problem. Whatever it is though, you guys got it to work, and that's the significant part... so if you can make it work, it can be done, and that's just that.
-
Well, you could take the crapshoot and just use CDRwin's bin instead of huc's ISO, and see if that presses, and shows up operational.
-
Gonna order some CDRs online... found a place that sells 'em, and they say that they ship to PR, but the dropdown for "State" didn't have PR on it. I was like "WTF MORONS".
-
I noticed a considerable size difference as well
Hmmm... I must have been looking at the wrong file. I don't know if I still have the actual files we burned, aside from the audio.
But yeah, the larger file from cdrwin contains the ecc codes (that's the difference in size). You need those to burn the (larger) mode1 track, otherwise the sector alignment gets screwed up.
I *think* if you put it all together, you should have a masterable cd. Just don't use Nero. Or, if you do, make sure it really burns a mode 1 track (not XA/form1).
.............
It's starting to look like Nero isn't adding the ecc codes correctly -or- it isn't burning the track correctly. I can't swear thats what is happening, but it sure looks like it.
And once we figure this out and have discs, someone needs to go back through this thread and figure out we did for posterity :)
Now, if it will still boot and play... <crosses fingers>
-
So, HuC strikes again?
lol
I don't use nero. Is it supposed to automagically assume it is supposed to add the error crap for you?
-
But.. HuC isn't outputting a wrong file, it's just outputting a cooked binary. >_>
7575792 vs 6596608
The original ISO is 6,596,608 bytes
The BIN ripped with CDRWIN is 7,575,792 bytes
There's nothing unusual about that. That's the size of a cooked binary vs a binary with mode 1 raw sector support bytes. Both those add up fine.
You guys know what cooked binary vs raw binary is, right? All cooked binaries are converted to 2352 byte sector as they're are written to the CDR (actually, in a buffer first and it's done by the software). Storing the ECC, EDC, SYNC, HEADER, etc additional bytes is redundant. Thus why cooked format is popular. Plus, you can directly edit the bytes with a hex editor or any software much easier. Cooked or raw, it doesn't change the LBA address of the data.
There's no such thing as a 2048 byte sector for mode 1. It's all 2352 bytes(plus 96 additional bytes for sub channel data). That is to say, all cooked and raw binary files end up being in mode 1 sector format (2352 without subchannel 96bytes) - assuming you choose mode 1. 2048byte is what's available as data. It doesn't throw anything off for the CD hardware reading the data. The LBA address and offset are the same regardless for CD data. Your LBA address is in sectors, not bytes. So if your LBA offset was 0x20 (relative to index 01) for a CD_READ, then it's gonna read 2048 bytes of data regardless that it's now the full mode 1 sector size. And those 2048bytes are going to be the same bytes as in the ISO HuC spits out (LBA_address * 0x800 = byte_address). There's another problem with an app making a RAW mode binary. If an app messes up the sync or header byte values and you burn it as is, you'll get read errors. It's more convenient to let the burning app handle this or an external app for conversion (well, IMO :D ). Anyway, here's a good site showing the mode 1/2/forms break down. (http://www.multimediadirector.com/help/technology/cd-rom/cdrom_spec.htm).
I don't doubt Nero is messing stuff up for you (making non bootable TurboCDs), but I've been using Nero for about 6 years or so without problems for making TurboCDs. I don't create mix moded discs or such in the project, I tell Nero to burn the CUE file (but I assume you guys are as well). I've been using 6.xx.x.x.x or something Nero and still use it. I have no idea about the new versions though (12 is the newest I think). I did have a problem once, but it turned out to be the drive. It wouldn't burn DAO RAW (it had to be DAO RAW/96, but I didn't include a sub channel file). I've had good results with Alcohol 120% too with burning TurboCD stuff (and even on laptop cdr drives). But if Nero is burning the data track as XA mode 2 form 2, then it shouldn't work on the PCE CD. Would probably work on the PC with some emulators as accessing the physical drive for an XA form 1 CDR data track (because it should be getting cooked data from the sector request for the app).
I don't use nero. Is it supposed to automagically assume it is supposed to add the error crap for you?
Every burning software that encounters a data file that's listed as mode 1/ 2048, yeah. It wouldn't burn right otherwise.
FILE "lords.iso" BINARY
TRACK 01 MODE1/2048
INDEX 00 00:00:00
INDEX 01 00:47:09
Ok, so Nero completely failed for you guys so the mastering company never got a CDR burned from Nero. Got it.
EDIT:
The Old Rover: If you can dump the CDR you burned in raw mode, I can show you where to look to see what format the sectors in the pregap are labeled as. That might shed some light on why eclipse is reading them as audio sectors/data (that's what the DDxxx whatever error looked like).
-
...You've also never sent a burned CD-R in to get pressed, so for all you know, you could have the same "working" discs as Rover. I've used Nero in the past to create discs to play on my CD-R. I wouldn't trust them to get pressed. Rover's shit he burns at home in Nero plays on hardware fine, but f*cks up at the pressing house. It may work on a the TGCD (where perhaps it is a bit lazy with reading through the ECC)...
but a pressing setup is a bit (a lot) more picky. "has to be perfect" picky.
I'm saying, a cooked binary may be throwing the whole process off, where a raw bin/cue extracted properly from CDRWin with the ECC injected properly before-writing doesn't.
So, Nero ends up writing a disc that accidentally runs on hardware, but is not correct.
-
Tom, Nero burns the ISO as MODE2, even if the cuesheet says to burn as MODE1. CDRWIN confirms this.
-
hah, so its burning as MODE2 (Form 1?), which has an 8 byte header at the start of the data section...
whereas Mode 1 has these 8 bytes as unused at the END of the data section.
probably causing an overlap....
Confirming that Nero is incorrectly burning the cooked ISO that HuC produces. Rather than stuffing in the proper ECC where needed like CDRwin does, it just decides HEY this is close enough! HAH!
... and ruins everything. Like I said, it will accidentally work if you play it, but won't confirm to the presser trying to create a Mode 1 disc. There is crap where it shouldn't be.
Sweet.
-
I verified it by using Nero to burn the ISO by itself to CDR, then used CDRWIN to rip the track from the CDR. Indeed, the resulting .cue stated MODE2/2352. Mounting the ISO with Alcohol 120% and then ripping that with CDRWIN resulted in MODE1/2352... success. :)
-
Mounting the ISO with Alcohol 120% and then ripping that with CDRWIN resulted in MODE1/2352... success.
Don't get too happy yet :)
Can you burn a bin/cue with alcohol 120? (I've never used it). If so, you need to build the cue and burn a test disc to make sure all the audio, etc works. And that it boots and runs.
If that works, you -should- have a good-to-go master. Here's hopeing :)
<crosses other set of fingers...and some toes>
-
Awesome work Nodt! :D Wow, so your Duo is actually reading a mode 2 form 1 data format. Mode 2 form 2 (which is just normal mode 2) was defined in Yellow book, but XA form 1 wasn't defined until 1991. Just speculation but maybe there's 'firmware' in the CD units that are more up to date. And some CD units that can only read mode 2 form 2, are reading the same data sectored but without applying ECC. Either way, mode 2 is for the birds...
Just curious, have you tried burning the ripping cue/bin from the virtual drive by CDRWIN, with Nero and rechecking it to see if Nero follow the raw format to the T?
This doesn't just help out for pressing, but for people burning CDRs too (on those finicky systems).
-
Don't get too happy yet :)
Can you burn a bin/cue with alcohol 120? (I've never used it). If so, you need to build the cue and burn a test disc to make sure all the audio, etc works. And that it boots and runs.
If that works, you -should- have a good-to-go master. Here's hopeing :)
<crosses other set of fingers...and some toes>
Gonna order some CDRs and test it... the ones I have right now are inadequate.
Awesome work Nodt! :D Wow, so your Duo is actually reading a mode 2 form 1 data format. Mode 2 form 2 (which is just normal mode 2) was defined in Yellow book, but XA form 1 wasn't defined until 1991. Just speculation but maybe there's 'firmware' in the CD units that are more up to date. And some CD units that can only read mode 2 form 2, are reading the same data sectored but without applying ECC. Either way, mode 2 is for the birds...
Just curious, have you tried burning the ripping cue/bin from the virtual drive by CDRWIN, with Nero and rechecking it to see if Nero follow the raw format to the T?
This doesn't just help out for pressing, but for people burning CDRs too (on those finicky systems).
Yes, the Duo was reading the MODE2 discs just fine, as long as I was using high-quality media and not cheap shit. I can verify this as well by ripping any one of the burned CDRs I've made over time. However, I wouldn't have known to even do this if not for Arkhan and TheOldMan, so the credit really goes to them.
-
Awesome work Nodt! :D Wow, so your Duo is actually reading a mode 2 form 1 data format. Mode 2 form 2 (which is just normal mode 2) was defined in Yellow book, but XA form 1 wasn't defined until 1991
I think basically everyones Duo/TGCD can read these. I used to burn downloaded games with Nero back in the day before I got CDRwin to operate. I've also had good luck with Alcohol 120% (It burns Bin/Cue, OldMan).
My guess is that since the CD Rom hardware is so old, its a bit lazy with things, and eventually does just find the data it wants, even if its a bit off.
My TGCD, white PCE CD, Duo-R, and the spare TGCD I sold, all read discs burned lazily with nero back when I was ~12 or 13.
It's accidental workage.
I'd also bet that if the pressing machine would actually allow the stamper to be made, the discs produced, while "incorrect" would still actually work.
Nodt, I guess this means we actually earned our Special Thanks spots in the credits? lol. (unless demoing it at a con was good enough? hah)
-
Nodt, I guess this means we actually earned our Special Thanks spots in the credits? lol. (unless demoing it at a con was good enough? hah)
You're both already in it, duh. :P
-
oh. right. lol
-
Alcohol 120% (It burns Bin/Cue, OldMan).
Good to know. I'll add it to my burner test software list.
My guess is that since the CD Rom hardware is so old, its a bit lazy with things, and eventually does just find the data it wants, even if its a bit off.
That would (I think) be part of the ipl code. I -think- the last 8 bytes would normally be 0, so if the first 8 bytes are 'nops' (or equivalent code) it would be okay.
Just speculation though. I'd have to burn a cd and boot it in an emulator, then breakpoint the load routine to find out. Maybe someday. Probably before pp gets pressed.
I guess this means we actually earned our Special Thanks spots in the credits?
No credit (or free copy) needed. Just get MSR finished and shipped, so you can work on Jungle Bros. That's the one I want to see :)
I'd also bet that if the pressing machine would actually allow the stamper to be made, the discs produced, while "incorrect" would still actually work
And I'll second that.
BUT, the CD presser won't take that chance. That's why they do all these checks. You got no comeback if -you- screwed the master up, they press it, and it doesn't work. Also why they bitch about track 2 being data. :)
(I don't think they will bitch about track 1 being data. That's a fairly common thing with newer mixed mode cds).
-
Hmm... I used cdrwin to look at a few discs I burned with Nero and they all show mode 1, not mode 2.
I did a new test burn and cdrwin read just to make sure:
(http://www.pcedev.net/cdr/cdrwin.png)
(http://www.pcedev.net/cdr/nero.png)
So I guess my version of Nero was working fine all along. But overall you can't trust Nero installed to a particular system or such. I dunno.
Nodt: Can you post the first three entries in your original CUE file (from the cue text file itself)?
-
but whats the origin of the ISO's you're using? Are they from HuC, or from something you downloaded off the internet?
-
but whats the origin of the ISO's you're using? Are they from HuC, or from something you downloaded off the internet?
For the one posted above, Super Raiden (downloaded) - it's a cue/iso/wave set (not a cue/bin). But I've tested my megaman one (the one with CD tracks) and it showed the same. The megaman one was assembled with PCEAS, which is what HuC uses (I created the cue sheet for the megaman CD by hand). But.. that doesn't effect anything. The ISO has no function other than being a data file, in a cue sheet. Only the switch in the cue file for the data track entry tells it how to interpret the binary ( mode 1/2048 tells it that it's a straight binary). Anyway, if you guys are having problems with Nero making mode 2 tracks when you specified a mode 1/2048 argument in the CUE sheet, then I'll definitely not recommend people to use Nero in the future. Or at least to double check it.
-
I am just curious if the ISOs you use have the info injected in like CDRWin does, or are they lacking it, waiting for the writer to add it for you.
-
The original cue file looks like this for the first three entries:
FILE track01.wav WAVE
TRACK 01 AUDIO
INDEX 01 00:00:00
FILE track02.iso BINARY
TRACK 02 MODE1/2048
PREGAP 00:03:00
INDEX 01 00:00:00
FILE track03.wav WAVE
TRACK 03 AUDIO
PREGAP 00:02:00
INDEX 01 00:00:00
-
I am just curious if the ISOs you use have the info injected in like CDRWin does, or are they lacking it, waiting for the writer to add it for you.
You mean like this? 00 ff ff ff ff ff ff ff ff ff ff 00 00 02 00 01
Nope. Just the same cooked binary liked HuC and PCEAS always puts out. (That string is the sync+header for a raw preped CD sector. First 12 bytes are the sync. Next three bytes are the address of the sector: minutes:seconds:frames. Last byte is the mode: mode 1). No, all the ISOs I have and use are cooked format. None are raw mode 1.
Thanks Nodt.
-
Downloaded the demo of Insanity and looked at the layout. It looks like you can't change index numbers for a whole binary image setup (data+audio in a single file). I looked at the first sector of index 01 in Insanity demo and the string reads:
00 ff ff ff ff ff ff ff ff ff ff 00, 00 28 27, 01
That's 28 seconds and 27 frames from absolute LBA 0. But in the file itself, it's located at 00:23:27. Add the 2 second pregap for the first track and the 3 second pregap for the data track, and you get 28:27. So the data sector in the file says where it's supposed to be (this is for the low level CD hardware to verify,seek to,etc) and of course the CUE sheet matches this. Anyway, my point being is that if you change the pregap size for this type of layout without changing the formatted binary file, the sector address markers won't align up. It would be up to the burning software to check for this and correct this. CUE/ISO(cooked)/WAVE doesn't have this problem as there are no address markers for the data sectors yet (the recording software does that in the buffer).
The other thing is, cdrwin doesn't dump any of the pregap data. That sucks. Those were the sectors that I wanted to look at (I wanted to see the sector format of them and what mode they are recognized as).
-
It looks like you can't change index numbers for a whole binary image setup (data+audio in a single file).
Yes, we knew that already, lol.
That's 28 seconds and 27 frames from absolute LBA 0. But i... etc. etc..... and of course the CUE sheet matches this.
Yes... lol
Anyway, my point being is that if you change the pregap size for this type of layout without changing the formatted binary file, the sector address markers won't align up. It would be up to the burning software to check for this and correct this. CUE/ISO(cooked)/WAVE doesn't have this problem as there are no address markers for the data sectors yet (the recording software does that in the buffer).
I thought we already covered this too, basically? It's part of why Rover's CD is messed up.
Also, the demo posted online is the ISO from HuC, plus a cuesheet I hand made. It has not been touched by CDRWin in any way.
Basically, Rover's problem is what we've already stated 2 or 3 timesish here. I'm betting that if he does the bin/cue extract, appends to the cuesheet for all the music files, and burns/resubmits to Nationwide, it'll be fine.
It's a product of modern burner software and modern CD hardware failing to be nice.
-
and burns/resubmits to Nationwide, it'll be fine.
Provided he doesn't burn it with Nero, and closes the disc (ie, burns DAO).
-
Yes, we knew that already, lol.
Yes... lol
Yes, it was stated something to that effect but it wasn't stated why. I'm the type of person that's not satisfied with 'because' or whatever for an explanation. I want to know the exact reason and details as to why. Plus, it wasn't clear what CUE format the statements were applied to.
I thought we already covered this too, basically? It's part of why Rover's CD is messed up.
What I posted has nothing to do with Rover. His original CDR from Nero booted fine in the real system. And he used an CUE/ISO/WAVE setup. You can change the pregap settings to all kinds (of legal) values in that kind of setup and the PCE will still boot fine. *I was posting details as to why index matching (possibly) matters to one type of layout (cue/bin) but not to another type of layout (cue/iso).*
Also, the demo posted online is the ISO from HuC, plus a cuesheet I hand made. It has not been touched by CDRWin in any way.
The demo I downloaded from online from your site was a CUE/BIN. One bin file; contained the data and audio tracks in a single file. It didn't have any cooked or ISO file of that of HuC. Maybe you didn't run it through CDRWIN, but either way it wasn't a CUE/ISO/WAVE set. It was a CUE/BIN. I burned it and ripped it back with CDRWIN as a CUE/BIN and it matched the downloaded bin perfectly.
Provided he doesn't burn it with Nero, and closes the disc (ie, burns DAO).
Actually, I'd be interested in see what his version of Nero does for a cue/bin set. I was hoping my version of Nero was doing what Nodt was, so I could test out my theory that Nero would burn it correctly if it had a cue/bin vs a cue/iso/wave. I know he has it working with alcohol or whatever he's burning the cue/bin with, I just mean for my own curiosity.
-
Yes, it was stated something to that effect but it wasn't stated why. I'm the type of person that's not satisfied with 'because' or whatever for an explanation. I want to know the exact reason and details as to why. Plus, it wasn't clear what CUE format the statements were applied to.
Ah, I'm the type to skimp on details that I feel are probably implied. I'm not big on tech blabbering. Oh well.
What I posted has nothing to do with Rover. His original CDR from Nero booted fine in the real system. And he used an CUE/ISO/WAVE setup. You can change the pregap settings to all kinds (of legal) values in that kind of setup and the PCE will still boot fine. *I was posting details as to why index matching (possibly) matters to one type of layout (cue/bin) but not to another type of layout (cue/iso).*
Index matching matters for pressing, since their stamper requires everything to line up exactly. Any inconsistencies, or "eh, good enoughs" will not go so well.
The demo I downloaded from online from your site was a CUE/BIN. One bin file; contained the data and audio tracks in a single file. It didn't have any cooked or ISO file of that of HuC. Maybe you didn't run it through CDRWIN, but either way it wasn't a CUE/ISO/WAVE set. It was a CUE/BIN. I burned it and ripped it back with CDRWIN as a CUE/BIN and it matched the downloaded bin perfectly.
OH, that's right. I ran the thing through CDRwin to protect my audio-files.
Originally the demo was chiptunes only. When I decided to post the CD music too, I fired it through CDRWin. The original bin/cue was simply a cuesheet + HuC ISO. I haven't grabbed that link in what, 3 years now. Forgot.
Rover could also probably do something like that for his burning endeavors to ensure properness.
Actually, I'd be interested in see what his version of Nero does for a cue/bin set. I was hoping my version of Nero was doing what Nodt was, so I could test out my theory that Nero would burn it correctly if it had a cue/bin vs a cue/iso/wave. I know he has it working with alcohol or whatever he's burning the cue/bin with, I just mean for my own curiosity.
I can't remember exactly, but can't you friggin rename an ISO to a .bin, make a cuesheet, and it works fine? lol
I'm not sure what all happens since I mostly did it for shits and giggles once many years ago. It might be worth f*cking with for a laugh to see what it does, and to see if you can trick Nero into working.
However, I've determined that CDRWin and Alcohol 120% are better programs to use. They seem to yield better results. CDRWin is king. Getting a machine for it, is rough.
-
*I was posting details as to why index matching (possibly) matters to one type of layout (cue/bin) but not to another type of layout (cue/iso).*
Because they are inherintly different types of activities. A cue/bin setup contains indexes to locations inside the .bin file. It is burned as is, so the indexes better match. I'm not aware of any software that checks/patches these internal indexes, so if you screw up where they are in the cue sheet, the cd doesn't work right.
Cue/iso format, however, builds the disk indexes from the locations of the seperate files.
And please note: you *can* move things around in a cue/bin setup. It just takes a hex editor and a lot of knowledge.
Easier to extract the seperate indexes and re-arrange the files, though.
Actually, I'd be interested in see what his version of Nero does for a cue/bin set.
It will burn it exactly as is. Do you think it will magically change the track types? No. It does a direct write.
It will probably abort if it detects errors, though.
As for the Cue/iso/wav, we already know that it changes Mode 1 tracks to mode 2/xa Form 1 tracks. At least.
Ah, I'm the type to skimp on details that I feel are probably implied. I'm not big on tech blabbering. Oh well.
Yes, it was stated something to that effect but it wasn't stated why. I'm the type of person that's not satisfied with 'because' or whatever for an explanation. I want to know the exact reason and details as to why. Plus, it wasn't clear what CUE format the statements were applied to.
Actually, neither of you are very clear sometimes.
"cooked" vs "raw" ? Yeah, I know what those mean, but isn't it clearer to refer to them as 2048 and 2352 byte sectors, so I don't have to remember (or look up) which is which?
And both of you are guilty of saying "Index 1" without reference to which track or file you are talking about. No, it's -not- always obvious.
As for wanting to know "exactly" what is going on...There are levels of details you don't need to understand at a particular time. You don't need to know -how- a track is formatted, exactly, to solve the problem of using the wrong track type. Bringing in those details obscures (*not* clarifies) the whole discussion.
But, if you must do that, go ahead. Let me know when you get to the muon/quark level. I find partical physics interesting, too.
(And if you really think you need those details, dd the CD in linux. You can get a complete byte-for-byte dump of everything. Yes, I have. And gone through it with a hex editor, too)
-
Actually, neither of you are very clear sometimes.
And both of you are guilty of saying "Index 1" without reference to which track or file you are talking about. No, it's -not- always obvious.
Yup, that is why I often shy away from tech yammering. Things that make sense in my head are often pretty gimped once I put them out. :)
I can think of like, two people who understand what I mean almost always. They "get" my wacked out way of explaining things :)
anyway, I think we've probably solved the problem, and just need to wait on Rover to get new CDs and burn stuff
-
Index matching matters for pressing, since their stamper requires everything to line up exactly. Any inconsistencies, or "eh, good enoughs" will not go so well.
The data track index matters just as much for the CDRs too, though. It's an all or nothing thing. If index 1 (of the data track) doesn't point to the start of the ID string for PCE CD identification, it won't continue on (CDR or pressed CD). Not to mention everything else won't align up either after that, but you won't even get that far. Which you guys already encountered on CDR if I read it right.
Bringing in those details obscures (*not* clarifies) the whole discussion.
But, if you must do that, go ahead. Let me know when you get to the muon/quark level. I find partical physics interesting, too.
Hehe, yeah ok. I'm completely guilty of going in that direction on a lot of things. But over all no, I don't particularly see additional attention to detail and information as a bad thing or that it clogs up a discussion. A lot of tech oriented discussion are like that IMO. At least on forums. A better understanding never hurt anyone IMO. But hey, that's just my personality type. I'm sure many partially or completely disagree. At any time, someone can say 'I don't care, just tell me specifically about <this>' and be on their way. Or just simply take what they want from the discussion and move on. And nor is this a realtime/real life discussion and have to worry about our target audience; we're technical minded here.
And please note: you *can* move things around in a cue/bin setup. It just takes a hex editor and a lot of knowledge.
Easier to extract the seperate indexes and re-arrange the files, though.
Hah, yeah. That would be a lot of hex editing (you'd have to edit every sector of the data track ;>_>).
I guess coming from a setup of binary files that weren't preformatted for CD sector format, I wasn't aware of this myself. You can have a large single file that's *not* mode 1/2352 formatted for the data track and the pregap *size* can be altered without problems (this has nothing to do with the offset the index uses). And on the opposite side you can have a cue/bin/wave format and the bin *is* mode 1/2352 format and it will be a problem. And that's to say if the CDR software doesn't correct this. At minimum, it should be checking this (every preformatted data sector) and at least reporting a problem in the log. Mode 1/2352 PCECD setups are looked down upon in the hacking and translation community because of the complexity it adds - without any perceivable advantage. Mode 1/2048 binary multifile setup is the best setup for patching the data track (using the preexisting patchers). I'm still convinced of this though. Just weary of recommending Nero for burning them.
It will burn it exactly as is. Do you think it will magically change the track types? No. It does a direct write.
It will probably abort if it detects errors, though.
Well... it was also assumed that Nero burned mode 1 tracks *when* told to, and yet it didn't for Nodt. So no, I'm beyond assuming anything at this point. It's the very point that Nero did this, that verification should be done. I've never seen a recording program automatically switch to mode 2, form <whatever> when it's told specifically to use mode 1. Nero is pretty popular and big name program. That's a pretty big f*ckup IMO.
Maybe I should clarify myself. The original topic of the thread was about how you guys solved the pressing house issue, but that was pretty much established early on in the thread. My focus has moved to what CDR burning software is doing to CUE and everything related to it. It's not just about the pressing house but about; the do's and don'ts, what software is f*cking shit up, what method is the best for a given situation, what are the pro's and con's of each type of CUE layout, etc. There people that do translation patchs or make their own stuff (homebrew) available for burning, etc. And believe it or not, there's still a lot of misunderstanding out there. I admit, it's probably mostly related to the translation scene for CDs - but that's part of my area of work in the PCE too. I mean, it still relates to pressing house issues - but also more than that.
Yup, that is why I often shy away from tech yammering. Things that make sense in my head are often pretty gimped once I put them out. :)
I can think of like, two people who understand what I mean almost always. They "get" my wacked out way of explaining things :)
I know you know your shit, even if you are a bit crappy at explaining technical things sometimes :)
Anyway, Nodt's got what he needed from you guys already. I don't doubt that it'll all be fine. I probably won't post any more details here then (I seem to be the only one really interested in looking at further details about this related stuffs). I'll just log and put away any my findings. And also much thanks for info, you guys. And Nodt, for verifying some stuff for me on your end :)
-
Sorry to resurrect this, but...
Bonknauts: You said you burned Lot (?) with stuff inserted in the pre-gap area.
Could you check in Nero (Recorder->Disc Info) and see what kind of CD it says it is?
For the life of me I *cannot* get Nero to burn anything other than what it says is an "Enhanced CD"
(ie, multi-session). I'm beginning to wonder if that's the problem. Maybe older software doesn't recognize
Enhanced CD's as different from standard CD-Roms.....
I'm really beginning to think the problem is the way Nero does TOC's.
-
Sorry to resurrect this, but...
Bonknauts: You said you burned Lot (?) with stuff inserted in the pre-gap area.
Could you check in Nero (Recorder->Disc Info) and see what kind of CD it says it is?
For the life of me I *cannot* get Nero to burn anything other than what it says is an "Enhanced CD"
(ie, multi-session). I'm beginning to wonder if that's the problem. Maybe older software doesn't recognize
Enhanced CD's as different from standard CD-Roms.....
I'm really beginning to think the problem is the way Nero does TOC's.
Here's a pic of a burn I just did:
(http://www.pcedev.net/pce_cdr_burning/nero_ver11_LOT-dualboot_discinfo.png)
You're telling Nero to burn from a CUE file, not a project file - right? What does your CUE file look like?
Also, this burn was done using Nero 11 under Windows 7 (for my XP boot OS, I use Nero 6).