Building Selfboot CDIs with Discjuggler Image Editor

[Xiaopang]

Recently I had the idea to try building selfbooting images with Discjuggler itself. It supports building multisession images and even directly supports the cd-extra-like structure of the mil-discs right out of the box. This could be useful to easily build 80min+ images in size with audio tracks, which isn't possible with the echelon method.

Creating the image is totally easy. The only thing I didn't manage to do was to insert the ip.bin into the first sectors of the second session. Does anyone know an image editor that allows sector editing? Alcohol 120 has an excellent sector viewer, but it doesn't allow to edit them. There has to be a similar working editor somewhere. Any ideas?

[Christuserloeser]

The newer versions of BootDreams allow CDDAs in DiscJuggler images:

BootDreams v1.0.3 Release (http://www.dcemu.co.uk/vbulletin/showthread.php?goto=newpost&t=62403)

[Xiaopang]

yeah, but according to fackue they are not selfbooting. still...i wanna make this method work...wouldn't hurt to have another way to make images, would it?

[fackue]

@Christuserloeser: It actually doesn't. cdi4dc doesn't support it yet. But CDDA however, is supported using CDRecord.


This could be useful to easily build 80min+ images in size with audio tracks, which isn't possible with the echelon method.
The size of the image shouldn't matter. But thinking about it, the tutorial is pretty much the same process (as BootDreams) since the tutorial doesn't create DiscJuggler images i.e. it explains how to use CDRecord.

[Xiaopang]

lately i realized that xeal released a cdda-version of bin2boot. that really works great for creating oversized cdda-images, but since those aren't burnable due to the boot code being at the end of the disc, i'm still looking for an answer of my prob. does anyone have any information about the structure of cdi-images? especially on manually creating sessions and tracks

[fackue]

You could use bin2boot, but you have to have a CUE file for CDDA.


that really works great for creating oversized cdda-images, but since those aren't burnable due to the boot code being at the end of the disc, i'm still looking for an answer of my prob.
bin2boot wouldn't be released if it didn't work. The boot code is supposed to be at the end of the disc. Dreamcasts do not read the boot code from the first track, ever unless it's a GD-ROM but that's not even the boot code - it's just the IP0000.BIN (quite irrelevant).


does anyone have any information about the structure of cdi-images? especially on manually creating sessions and tracks
If you really want to know, look up libdiscmage. It's a C library that explains how DiscJuggler 4.0 headers work (among others).

[Xiaopang]

You could use bin2boot, but you have to have a CUE file for CDDA.

i did and it works great. my current project is 99:59:30 in size right now and it works in nulldc, although this requires to hack the bin-file and remap the audio tracks since track 1 isn't an audio track as expected by the app, but the data track. i'm working on that, but i'm still at deciphering the hex-structure of the sound-code




bin2boot wouldn't be released if it didn't work. The boot code is supposed to be at the end of the disc.

i know and thats the problem. data/data requires the cd-writer to open a new session at the end of the disc which seems impossible if the disc size is beyond what is defined in the orange-book standard. the normal atip of the cd-r , which is necessary for the laser to stay calibrated while burning, covers only 80minutes. even on bigger sized cd-r's. 99min discs show up as 80min-cd's but are guaranteed to write up to 99 min. however, i think that writers are not capable of opening a new session between 80 and 99 minutes, because of the atip not covering that area. at least my writer can't handle it. so the only way around that is to use audio/data, because the second session begins in the area that is covered by the atip, so overburning is no problem at all.

thats why i want to find a way to replicate the audio/data-method with cdda for oversized discs.




If you really want to know, look up libdiscmage. It's a C library that explains how DiscJuggler 4.0 headers work (among others).

thats a cool info! thanks!

[fackue]

i did and it works great. my current project is 99:59:30 in size right now and it works in nulldc, although this requires to hack the bin-file and remap the audio tracks since track 1 isn't an audio track as expected by the app, but the data track.
Don't hold me on this but if bin2boot creates a .cdi with CDDA it will put them in the first session, otherwise AFAIK it wouldn't be selfboot if they were in the second session. I never looked into it so if you know otherwise please show me.


99min discs show up as 80min-cd's but are guaranteed to write up to 99 min.
Hmm, I didn't know that. Do you have proof?

[Xiaopang]

Don't hold me on this but if bin2boot creates a .cdi with CDDA it will put them in the first session, otherwise AFAIK it wouldn't be selfboot if they were in the second session. I never looked into it so if you know otherwise please show me.

actually, the image it creates is data/audio/data. it places the application data in front, just like it normally would, but before appending the boot data, it inserts the audio tracks. thats kind of a strange format, but it works. of course the application has to edited to the new track layout accordingly, but otherwise it works fine




Hmm, I didn't know that. Do you have proof?

yeah, all my 90 min and 99min discs show up as 80min discs in whatever software you use to get some infos about them (nero, dj, etc)
also, this is quite common knowledge for users of these kinda discs. here is an excerpt from wikipedia:

"Most CD-Rs on the market have an 80 minute capacity. There are also 90 minute/790 MiB and 99 minute/870 MiB discs, although they are rare. Some drives use special techniques to write more data onto a given disc, such as Plextor's GigaRec allowing as much as 1.2 GiB onto a 99 minute disc. Also, due to the limitations of the data structures in the ATIP (see below), 90 and 99 minute blanks will identify as 80 minute ones and have to be burned using the "overburn" options in the CD recording software."

http://en.wikipedia.org/wiki/CD-R

[SiZiOUS]

You could use bin2boot, but you have to have a CUE file for CDDA.
Cue files are supporting multisessions ? Or do you mean two cue files for one image ?

[fackue]

Cue files are supporting multisessions ? Or do you mean two cue files for one image ?
Actually, I'm talking about the nonselfboot images with CDDA.

[Xiaopang]

Cue files are supporting multisessions ? Or do you mean two cue files for one image ?

nope, unfortunately they don't support multisession. you only use the standard non-booting bin/cues. bin2boot treats them as one session and appends its bootcode as another one