Earlier SEGA docs call them "Single-Density" and "Double-Density" areas, more recent revisions call them "Single-Density" and "High-Density". No "Low-Density" anywhere.

27 (edited by Jackal 2018-12-19 06:31:04)

I think it would be better to skip dual cuesheets completely and stick to the single cue with the proposed improvements? It's just way more practical. Multi session discs should have a similar solution.

28 (edited by redgoo 2018-12-19 21:55:12)

Regardless of the format used, I think it is very important for preservation purposes to get the makers of Optical Disc Emulators and software emulators on board to support it. There are two widely used ODEs that work on original Dreamcast hardware:
GD-Emu - https://gdemu.wordpress.com/details/gdemu-details/
USB-GDROM - http://3do-renovation.ru/USB-GDROM_Controller.htm

Very happy to see progress! I will be submitting a handful of new dumps soon.

As a start i began with this single-cue file alternative:
http://redump.org/disc/57702/

If it looks good to you i will update all remaining functions and all GD-ROM cuesheets.

As a backup i would still keep the gdi downloads, but if you think its completely pointless i will discard those.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Someone should try to contact Daemon Tools guys for the possible support of such cues.

31 (edited by Jackal 2018-12-25 08:44:16)

If you want to conform to the standards that are already set by IsoBuster with multisession discs, and have the best compatibility with other tools, the cuesheet should be like this:

REM SINGLE-DENSITY AREA
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

edit: Because the HD area apparently starts with Track03, we no longer need to think about Multi-Cue or other alternatives.

HD Area always starts with Track 3 and it is labeled as Track 3 in the subchannels. The areas are isolated, but they share the track numbering.

33 (edited by Jackal 2018-12-25 10:55:09)

The start address of the first Track03 sector is 10:02:00.

When we use a normal single cuesheet (with or without REM), the problem is that normal applications place the Track03 start time relative to the previous tracks.

So in order to get the correct sector addressing, a PREGAP will needs to be calculated based on the length of the previous 2 tracks.

Example: http://redump.org/disc/52815/

10:02:00 minus the combined length of the LD tracks (17:07) = 09:42:68

With this cuesheet, IsoBuster correctly loads the Track03 filesystem and other applications like CDmage have the correct sector addressing:

REM SESSION 01 ; SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM SESSION 02 ; HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 09:42:68
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

What do you guys think about this implementation?

It would require some extra coding, but it maintains the existing "standards" for .cue.

I've already mentioned such a solution. The problem is that such a cue is only "correct" for isobuster, other tools will "see" this track 9+ minutes longer than it should be, so it's not a good solution at all. The only proper way without implementing new commands would be to put everything into a single image.

REM SESSION 01 and REM SESSION 02 are also wrong, these commands generate a multisessional disc TOC, while GDs aren't multisessional, those are 2 separate images written on the same media (or 3, if to count the security ring area).

The GD image should NOT be seen as a single image with all the tracks at a time, that's why I've offered to do separate cues, so you could load them independently, just like a real thing. You either load and work with the LD area with 2 tracks or with the HD area with the track 3 and beyond (if any), not both.

35 (edited by Jackal 2018-12-25 12:26:45)

F1ReB4LL wrote:

I've already mentioned such a solution. The problem is that such a cue is only "correct" for isobuster, other tools will "see" this track 9+ minutes longer than it should be.

Actually, Track03 is shown with the correct size and starting address.

The only problem is that the Track02 end address aligns with Track03, but when you browse outside of the data range, it gives read errors.

I don't think this is a problem, it's merely a restriction of the .cue standard.

REM SESSION 01 and REM SESSION 02 are also wrong, these commands generate a multisessional disc TOC, while GDs aren't multisessional, those are 2 separate images written on the same media (or 3, if to count the security ring area).

I only suggested it because it's the only way to make IsoBuster detect the filesystem of Track03. But for emulators etc. we could stick to REM SINGLE-DENSITY AREA and REM HIGH-DENSITY AREA.

that's why I've offered to do separate cues, so you could load them independently, just like a real thing. You either load and work with the LD area with 2 tracks or with the HD area with the track 3 and beyond (if any), not both.

You still need the PREGAP line, even with separate cue's, because otherwise you would be pointing Track03 to start at sector 150 instead of 45.150.

So, I think this solution still stands?

Demolition Racer - No Exit (USA).cue wrote:

REM SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 09:42:68
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

Or tell us what the benefit would be of having 2 .cue's, like this?

Demolition Racer - No Exit (USA) (LD).cue wrote:

REM SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

Demolition Racer - No Exit (USA) (HD).cue wrote:

REM HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 10:02:00
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

Jackal wrote:
F1ReB4LL wrote:

I've already mentioned such a solution. The problem is that such a cue is only "correct" for isobuster, other tools will "see" this track 9+ minutes longer than it should be.

Actually, Track03 is shown with the correct size and starting address.

The only problem is that the Track02 end address aligns with Track03, but when you browse outside of the data range, it gives read errors.

I don't think this is a problem, it's merely a restriction of the .cue standard.

The problem is that you're adding the non-existant pregap that changes the track layout. From the preservation POV it's as bad as our misaligned gdis, just in the cue form.
I'd recommend to try to discuss the new format with IsoBuster guys instead, maybe they could implement our cues.

You still need the PREGAP line, even with separate cue's, because otherwise you would be pointing Track03 to start at sector 150 instead of 45.150.

Track03 image doesn't contain the pregap, so you aren't pointing at anything, it's upto the virtual drive/dc emulator/isobuster/whatever else to process the cue properly according to the REM commands and align the data properly. You don't add any pregaps to the normal data-only images, even if they have a pregap at the -150 to -1 area, why should you add it to the HD area?

So, I think this solution still stands?

Demolition Racer - No Exit (USA).cue wrote:

REM SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 09:42:68
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

Or tell us what the benefit would be of having 2 .cue's, like this?

Demolition Racer - No Exit (USA) (LD).cue wrote:

REM SINGLE-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

Demolition Racer - No Exit (USA) (HD).cue wrote:

REM HIGH-DENSITY AREA
FILE "Demolition Racer - No Exit (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    PREGAP 10:02:00
    INDEX 01 00:00:00
FILE "Demolition Racer - No Exit (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Demolition Racer - No Exit (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

I don't like that PREGAP thing. Other than that, both variants are fine. The 2xcues variant's benefits: it doesn't need any new REM commands; it allows to load LD and HD areas separately (technically, it shouldn't be loaded as a single image)

I don't think setting a PREGAP line is the right solution.

We could stick to a single cue example and make other REM lines, stating the next LBA starting address, which also could allow us to dump and link other inaccessible disc areas like security rings and gaps between multiple sessions.

It could look like that:

REM SINGLE-DENSITY AREA START LBA *here number*
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA START LBA *here number*
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

Anything between Track2 end sector and REM HIGH-DENSITY AREA START LBA would be emulated as a GAP without having to set any pregap values and would not require extra FILE lines.

REM SECURITY AREA START LBA *here number*
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (*here anything*).bin" BINARY
  TRACK ?? MODE1/2352
    INDEX 01 00:00:00

Not sure how to solve the "TRACK ?? MODE1/2352" part at this point, but there is probably a solution for that too. At this point its not a requirement.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

You need more commands, like REM LEAD-IN and REM LEAD-OUT to properly generate or insert the needed amount of sectors between the sessions/areas. And for describing the full GD structure, you would also need a REM MIRROR AREA command.

Or, if those areas are more or less standard (I haven't investigated too far), something like REM SECURITY AREA TYPE 1/REM SECURITY AREA TYPE 2 could be enough (same for the Saturn rings).

F1ReB4LL wrote:

You need more commands, like REM LEAD-IN and REM LEAD-OUT to properly generate or insert the needed amount of sectors between the sessions/areas

For inserting, yes.
For generating, no.

We don't dump them at this point, and besides of that not all leadout sectors will be dumpable. Not sure if we ever will have them included. Maybe its better to concentrate on GD topic right now smile

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

40 (edited by Jackal 2018-12-25 14:14:29)

I like this solution:

iR0b0t wrote:

REM SINGLE-DENSITY AREA START LBA *here number*
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA START LBA *here number*
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    INDEX 01 00:00:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 4).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA) (Track 5).bin" BINARY
  TRACK 05 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 00:03:00

As long as the start address of a track can be specified, there is no more need for PREGAP.

Maybe add a separator between the data area description and the start address, e.g. like this:

REM HIGH-DENSITY AREA ; START LBA 45150

and should we use LBA or MSF?

REM HIGH-DENSITY AREA ; START MSF 10:02:00

or a more abbreviated (but less descriptive) alternative, where the second part value is assumed to be the start address:

REM HDA 45150

Or a description with spaces would require " "

REM "HIGH-DENSITY AREA" 45150

And yes, this standard could be used for other disc types, e.g. multi session, and more data areas could be added when needed.

A separator is not really needed. Anything between "REM" and traling "START LBA NUMBER" is to be treated as a plain comment or a COMMAND, which will be recognized if its called "SESSION NUMBER" or "LEAD-IN" or "LEAD-OUT" or whatever commands you want to have there.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

SINGLE-DENSITY AREA always starts at 0, HIGH-DENSITY AREA always starts at 45150, additional commands aren't needed here. These are to be discussed later for the multisessional discs (though, even they should have REM LEAD-OUT and REM LEAD-IN generating commands, not that LBA thing).

You know that they start there because you are aware of that, but mounting tools do not know it.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

44 (edited by Jackal 2018-12-25 14:31:30)

F1ReB4LL wrote:

SINGLE-DENSITY AREA always starts at 0, HIGH-DENSITY AREA always starts at 45150, additional commands aren't needed here. These are to be discussed later for the multisessional discs (though, even they should have REM LEAD-OUT and REM LEAD-IN generating commands, not that LBA thing).

iR0b0t wrote:

You know that they start there because you are aware of that, but mounting tools do not know it.

Yeah, but anyway: REM NAME / START LBA  is also a new implementation that isn't supported yet by any software.

If you want to assign a unique command for dreamcast discs that assumes fixed starting positions, then maybe 'LDA' and 'HDA' are better names.

So what? Your "START LBA"/"START MSF" commands won't teach the mounting tools to do that, you need to tell the devs to code the support. So they can simply write the code to put the "REM HIGH-DENSITY AREA" data at 45150. You're overcomplicating things.

If there's no agreement on the single cue format, do the 2xcues with no additional tags. Easy.

"REM HIGH-DENSITY AREA" would be dreamcast exclusive, a global command would make more sense imho.

2xcues would be still dreamcast exclusive (without further REM commands)

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

48 (edited by Jackal 2018-12-25 14:50:06)

iR0b0t wrote:

A separator is not really needed. Anything between "REM" and traling "START LBA NUMBER" is to be treated as a plain comment or a COMMAND, which will be recognized if its called "SESSION NUMBER" or "LEAD-IN" or "LEAD-OUT" or whatever commands you want to have there.

I think it should start with a real command and require input of a number, for uniformity and to allow other uses besides dreamcast.

REM <COMMAND> <OPTIONAL DESCRIPTION> <START LBA NUMBER>

REM AREA "SINGLE-DENSITY" 45150

or

REM START "SINGLE-DENSITY AREA" 45150

Where the " " are optional and the last number is assumed to be the start address?

Honestly, I would be fine with what you suggest @F1ReB4LL but in the end the emulaton / mounting devs have to adapt their tools to that. Independently of what they would accept, if I developed such a tool myself I would rather prefer a global command which can be used on any system, not just one.

Let the devs know and arrange an adaptation, if they decided something I will go by that, its not a big deal.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

50 (edited by Jackal 2018-12-25 14:43:34)

iR0b0t wrote:

Honestly, I would be fine with what you suggest @F1ReB4LL but in the end the emulaton / mounting devs have to adapt their tools to that. Independently of what they would accept, if I developed such a tool myself I would rather prefer a global command which can be used on any system, not just one.

Let the devs know and arrange an adaptation, if they decided anything I will go by that, its not a big deal.

See my previous post. I agree it would be best to implement a global command. What do you think about my suggestion?