Pressing CDs

[nodtveidt]

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.

[Arkhan]

oh.  right. lol

[TheOldMan]

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

[Bonknuts]

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:



 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)?

[Arkhan]

but whats the origin of the ISO's you're using?  Are they from HuC, or from something you downloaded off the internet?

[Bonknuts]

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.

[Arkhan]

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.

[nodtveidt]

The original cue file looks like this for the first three entries:

Code: [Select]

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

[Bonknuts]

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.

[Bonknuts]

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

[Arkhan]

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.

[TheOldMan]

and burns/resubmits to Nationwide, it'll be fine.

Provided he doesn't burn it with Nero, and closes the disc (ie, burns DAO).

[Bonknuts]

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.

[Arkhan]

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.

[TheOldMan]

*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)