Pressing CDs

[Bonknuts]

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?

[Arkhan]

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.

[Bonknuts]

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.

[Arkhan]

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

[Bonknuts]

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

[nodtveidt]

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)

[Arkhan]

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.

[Bonknuts]

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?

[TheOldMan]

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.....

[Arkhan]

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.

[Bonknuts]

Oh, so it passed the master process then with the audio track first. Nice

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?

[Bonknuts]

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.

[TheOldMan]

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.

[Arkhan]

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.

[nodtveidt]

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.